Unlike, say, sending a probe all the way to Mars then having it burn up because two teams used different measurement units and forgot to convert them?
You can't rely on people remembering to convert units--they will make these mistakes. The problem is that the US hasn't converted to the metric system, and that NASA software apparently does not use type systems and data files containing units throughout. Those aren't stupid mistakes, they are on-going, deep-rooted problems, and they will cause more crashes, guaranteed.
The problem there wasn't the fact that people used wrong units in that one case. The problem was that (1) the US hasn't standardized on the metric system along with the rest of the world, and (2) that the NASA engineers didn't have software engineering procedures in place that required the presence of units on all data. Those are on-going, deep-rooted problems, and they are going to cause crashes and other problems over and over again until they get addressed.
I stopped using them years ago, both because of their handling of packages and because of their use of digital signature pads (which leave you with no recourse when they claim that they have your signature). I found Fedex and DHL to be considerably better.
Given that a lot of smart people were working on this for a long time, I doubt it was "titanically stupid mistake".
Here is a random guess at a scenario: someone dropped something or the detector was filled to quickly. The implosion of the first detector caused a chain reaction and caused nearby detectors to implode as well. You have to expect that these kinds of accidents happen.
I suspect that the people who built the device simply didn't expect a chain reaction of implosions. Maybe one can argue in hindsight that they "should have" thought of it, but it's not like people regularly build things that have thousands of vacuum tubes deep under water.
What would be stupid is if they anticipated the possibility of a chain reaction of implosions and decided "oh, we just aren't going to drop anything accidentally". We'll have to see whether anything like that eventually comes out. Until then, I'd hold my judgement.
It sounds like a very viable solution, being simple to understand, transparent to use, and fair to the webmasters and users involved.
You can bet that any intermediate would try to take their cut--the "web master" would only get a tiny fraction of that if anything at all. Besides, such a flat pricing model is too expensive for some sites and too cheap for other.
We have a free market that decides these things. I'm all for offering support for micropayments, but a one-size-fits-all approach just doesn't appeal to me.
Further, when I hear people rave about Java, it is more for the libraries it offers than for the syntax.
The language is clearly not what makes Java interesting--it's a conservative, somewhat tedious language. The libraries are quite good. But the runtime and its specification what makes Java really interesting from a systems point of view because it offers
a well-specified, complete reflection interface.
a well-specified, complete interface for dynamic code generation.
a well-specified set of interfaces to the garbage collector.
complete specification of what operations must throw what exceptions under what conditions.
complete specifications of both statically typed and dynamically typed operations (in particular, numbers behave with predictable efficiency).
implementations that actually reliably perform cross-compilation-unit inlining and other dynamic optimizations.
This makes it straightforward to implement bullet-proof and portable code walkers, debuggers, inspectors, novel efficient object systems, code instrumentation systems, transparent persistence and transparent remote objects, and lots more.
Lisp is a great language, but it traditionally has not interfaced as well with the Real World as a number of other languages that were more practically oriented.
It's not Lisp in general. Lisp integrates just fine with lots of environments. Lisp can integrate very well with UNIX if you let it (Elk Scheme and Bigloo are an excellent examples). And traditional Lisp implementations had everything from the assembler on up built-in and written in Lisp.
I think many of the people who developed CommonLisp and the Lisp machine just had a deep disdain for anything UNIX-related and therefore couldn't care less whether CommonLisp integrated well with UNIX or the kinds of things people were doing on UNIX. Just read the UNIX Hater's Handbook, contributed to by many vocal Lisp users in the the 1980's. As a result, CommonLisp has endless provisions allowing for pathname syntax on TENEX or oddball byte sizes, but few of the things that make systems like Perl, Python, or even Java so useful on UNIX and Windows. Other essential facilities didn't make it into the standard probably because many CL vendors thought they could use essential proprietary functionality as a way of binding users to their product.
I hope future Lisp implementations will learn from these past mistakes. CMU CommonLisp, in my opinion one of the best implementations around right now, might do well to just forget going for ANSI CL compatibility and instead come up with a more useful, more complete, and more streamlined feature set.
Well, I have XP on my laptop, because that's what it came with. Is it particularly stable? Well, that's open to debate. No blue screens (so far), but lots of dialog boxes of the form "something really bad happened, but I'll see what I can do". I needed to reboot a few times because it got into weird states. Seemes more like they kludged around problems rather than fixing them. In terms of UI and configuration, XP is slightly worse than previous consumer versions of Windows, although it looks a bit slicker. Networking was actually pretty tricky to get working. And, of course, its APIs are as mediocre as always.
But the biggest problem with XP is its rampant commercialism. Windows, other Microsoft applications, and third party applications constantly bug you for personal information, registration information, etc. And who knows what information it's sending out behind my back. And I already spent about $100 on third party utilities.
Altogether, XP is something I could do without: it runs on applications I want to run, and the software I need to run on it is not particularly high quality. The only reason I have it is because Microsoft has managed to monopolize the market so much that there are applications you simply have to use in business and that only run on Windows. Yuck.
But the student is entitled to some of the royalties because they were a major part of the research.
Having your name on the patent doesn't entitle you to anything. Most inventors never see a dime from the royaltees on their patents--it all goes to the assignee. If the school has an enlightened policy and if they actually own the patent, they may give students and researchers a cut of the royalties, but even then, they are not under any obligation to be fair about it--they might well decide only to reward professors and postdocs, no matter who is listed as co-inventor. If the research was sponsored by a company, often, none of the inventors sees any money beyond the grant.
It doesn't matter whose name is on the patent--the patent needs to be assigned to the school or the organization sponsoring the research anyway. Some schools have fairly liberal rewards for patents while others don't, but the actual rights in the patent will in any case not remain with the researcher. If the research was paid for by public funds, as most biomedical research is, the public should expect (though in these times doesn't always get) the rights to any invention--that is, it should be placed in the public domain.
Apparently few seem to agree with you (and some others) that X11 works "well" on this current crop of handhelds. "Well" is obviously a relative term but the performance bar are other existing embedded systems as QT Palmtop Environment and Microsoft CE.
Well, on the iPaq, you can actually compare this on the same hardware: I find X11 runs better than WinCE (in addition to being more robust and easier to program).
I haven't been able to do a side-by-side comparison with Qt/Embedded, but according to Troll Tech's own specs, it seems to require more resources than X11.
At least the Sharp has a USB port
The Sharp hardware is nice. Let's hope they'll see the light and support a completely standard Linux environment.
Just because sharp haven't done everything for you doesn't mean it is useless
Well, if you use X11 on it, you effectively lose all the built-in apps, which want to write directly to the screen buffer. That, or you have to do a lot of really hard work on X11 to make it integrate with Qt/Embedded. I think getting a different Linux PDA is a whole lot easier.
I run VNC, MP3, video streams, games, and backups over 802.11b. If wireless gets faster, that's nice. But I don't really have a desparate need for it, and I suspect few other peopled do either.
I checked with Sharp. The device does not run X11 and, according to Sharp, there are no plans of offering it. That means that any application you write for the SL-5000 has to be either in Java or it has to be written for Qt/Embedded. Forget about easily porting existing applications you may have unless they happen to be written in Qt already. I suspect that this will prove to be a fatal limitation, but time will tell.
I'll stick with my Palm as an organizer, and with the iPaq using the Familiar distribution for developing special purpose handheld software. You can pooh-pooh X11 all you want, it works well, it uses no more resources than QTE, it's free, and it manages to run Gtk+, FLTK, wxWindows, and Qt, all on the same screen.
The reasons you cite for Lisp not meeting your needs (high prices, performance problems, lack of integration with the host environment) may have been valid complaints regarding the available Lisp systems of yesteryear, but are hardly relevant today.
I think they are as relevant today as they were five years ago. If you stick with the CommonLisp standard, you only get very limited functionality. If you use the full spectrum of functionality available in any particular implementation, you make yourself a member of a tiny user community and dependent on some small company. Calling both CommonLisp and the vendor variants collectively "Lisp" is as misleading as it would be to refer to C#, Java, and C++ collectively as "C".
Compare the CommonLisp situation with, say, Java. If you write applications in Sun Java, you are writing for a platform with a huge user community, a vast set of libraries with detailed documentation, excellent performance, lots of dynamic and reflective features, and negligible licensing costs (too bad about the syntax, though). If Franz or some other vendor managed to do the same Job with their CommonLisp variant as Sun did with Java, I'd switch back in an instant and would have no problem using the system commercially.
High performance Lisp systems which are well integrated with their host environments are readily available at all price points.
Well, I've used Franz, CMU CL, AKCL, GCL, CLISP, Bigloo, and PLT. I have also checked the implementations at lisp.org every now and then. Which system are you thinking of?
Bromley and Lamson's "Lisp Lore" most certainly does talk about source code debugging.
No contradiction there. My claim was that source level debugging didn't make it out to customers until the late 1980's. Bromley/Lamson came out in 1987. I was referring to Bromley's Lisp Lore, which came out in 1986 and AFAIK doesn't talk about it. With Genera 8, the Lisp machine became a much better system, with better debugging support and a better GUI, but it was too late.
I don't care if it's Oracle or RedHat -- the pay-for-support model sucks. It encourages the vendors to ship obscured and difficult products and to not publically release information.
I agree that if free software is created by the same people intending to support it, that is a problem.
But free software doesn't disable free market mechanisms. If RedHat ships software that sucks in order to drive up support costs, you don't have to use their software--you can pay someone to create the kind of software you like (perhaps as part of a collective bidding process).
So, overall, that's not an argument against free software in general, or against the ability to have an efficient market built around free software, it's an argument about one particular broken way of creating free software.
If MS gave away office, then they would make zero bucks off of ford for office.
And what exactly is wrong with that? Assuming for the sake of argument that Word was the only game in town, you would have paid handsomely for upgrades from Word 3.0 to Word 97 give how lousy early versions of Word were. But between Office 97 and Office 2000, there were almost no enhancements anybody wanted. Microsoft manages to force companies to pay excessive amounts of money for upgrades they don't need and they don't want--this is not an efficient free market at work.
Dunno if my point comes accross, but 'small apps' don't net money in the service/support arena, only in initial sales. If the 'small app' is free, then...
People who need a small app pay for it initially, and then it becomes free. The programmer who created it gets paid, and that's it--there are no further profits. Why should there be? In an efficient market, the price of a product represents the cost necessary to produce it. If the small app doesn't quite do what you want, you can hire another programmer to enhance it and pay for it; the amount of money involved is so small that this doesn't really fall prey to the tragedy of the commons, as real-world experience with open source software shows.
The problem with RMS's view of embracing the same development methods and openess that FS does is that with such a method you can not make money on software. If you have to give the source code away for free to others, how can you make money from it in a practical sense?
Sure you can: with consulting, contract work, training, and documentation. Such a software economy has many advantages: it encourages innovation because the same software isn't created and marketed by zillions of companies, it speeds up innovation because people can build on existing software, it increases efficiency because end users pay for a feature only once rather than over and over again with each upgrade, and it means that programmers get to do more interesting work and offers them a chance to work much more as independent economic agents.
Of course, you cannot built Microsoft or Oracle-style empires in such a software economy. You also cannot have stock prices that go through the roof. Instead, you reward an hour of work with an hour's worth of pay. Opening up software brings it back from being a plaything of corporate megalomaniacs and monopolists to individual craftsmenship. That is, it brings individual skill and free enterprise back into the equation.
The sad fact is that there is a lot of stuff you can put into code these days that exposes you to civil and criminal liability. People will try to bring claims of patent infringement, circumvention, copyright violations, and hacking against you.
And open source is at a grave disadvantage here: when Microsoft violates the GPL, nobody will know about it because it is hidden in gigabytes of messy binaries. But when Apache or the Linux kernel steps on someone's toes, everybody knows about it right away because the source code is open and widely read.
I don't have a solution for this problem other than that we need to become more active politically: open source software should not be at this disadvantage. But until the laws are fixed, decisions like Cox's, will be both rational and increasingly common. Stopgap technological measures, such as anonymous posting of such information, may help in the meanwhile, but they are far from perfect, both because they don't actually remove the legal liability and because they make development unnecessarily cumbersome.
Source level debugging was documented at least as of Genera 7.0 (1986). If you wished to compile your definitions with source level debugging information you had two (documented) ways to go about doing this. The first was to compile your forms within the editor using c-m-sh-C, also known as "Compile Region Toggling Locators".
The people I asked around the MIT AI lab didn't seem to know about it at the time, and as a Lisp machine user for half a dozen years, I never came across it in the voluminous documentation. I don't think "Lisp Lore" mentioned it either. I think if you look at how you say this was "documented", you can figure out yourself why nobody knew about it. Compare this with Smalltalk-80, which already had rich, obvious, powerful source level debugging around 1980 and presented the facility in an obvious, easy-to-use way. Overall, I think the Lisp machine had a decent development and debugging environment, but I personally wouldn't call it ground-breaking.
While I found the Newquist book to be a fun read, it gets a large number of otherwise easily verifiable facts wrong. I certainly hope you did not reach your conclusions using only that book as a reference!
Actually, my conclusions are based on my own experience: I was a Lisp machine user for half a dozen years and a CommonLisp user for a dozen years. I tried hard to introduce CommonLisp at several research labs and companies, but eventually gave up, for the reasons that I mentioned: the implementations cost too much and writing code that was both portable and efficient was a lot of work, negating much of the productivity advantage. Furthermore, the Windows and UNIX versions of CL never really seemed to integrate well with their environment.
I consider it a rather sad history because CommonLisp was quite a ways towards being a really great language and environment. Fortunately, many of its ideas live on in a variety of modern languages. And maybe, just maybe, CMU CL or some variant of Scheme will pick up the torch: a good open-source implementation that avoids some of the ANSI CL hair and integrates well with its environment might get picked up again by more users.
First, not that it matters really, but you're just wrong about source level debugging. It was present in Lisp Machines much earlier (two or three major releases and a half dozen years) than you realize. It wasn't turned on for Lisp for unknown reasons"
Seems like you are confirming what I'm saying: the Lisp machine did not have source level debugging until Genera 8. Whether it was hidden somewhere in the source code where your customers couldn't get at it hardly matters.
Second, you're also wrong about what killed Lisp Machines. [...] The Lisp language did not cause the problem.
I didn't claim that Lisp caused the problem. I claimed that poor business decisions, i.e., delivering an overly expensive niche market product, killed Symbolics and LMI and gave Lisp a reputation for being expensive and complex, something you, again, seem to confirm.
To be honest, I don't really understand why it's important to someone to declare a language or community dead while there are people using the language and happy with it. [...] destructive to take a posture of such definitive negativity that can't possibly aid you in any way and can, by confusing people with misinformation, injure others.
You are still operating under the mistaken assumption that Lisp has become marginalized because I or others have an irrational dislike of it. Quite to the contrary. I think Lisp is the greatest thing since sliced bread. That is why it has been so painful to see its decline over the last two decades, a decline I attribute to greedy and poor management at various Lisp vendors and a poorly conceived standard for CommonLisp.
I hope a new generation of researchers and programmers will learn from this history and that over this decade, Lisp will make a comeback. But that's why it is important to understand what went wrong in the first place.
Another interesting link about the history of Lisp and the Lisp machine is here, which basically reaches the same conclusion that I did.
Oh, and if you would like to experience a little more the sensitivity and humility with which many in the Lisp machine community have criticized other systems, just take a look here.
Copyright holders need "permission" because copyright itself is a privilege granted by society: we give you these extra rights for a limited time and a costly legal apparatus for enforcing them, and you distribute your works widely.
Arguably, copyright holders who encrypt their works aren't living up to their side of the deal. If copyright holders don't live up to their side of the deal, why should society live up to its side of the deal?
I understand why the Europeans ultimately gave in to industry demands, and this is not a simple decision. But I think in the long run, this is a mistake. Content creators should choose between either free and open distribution coupled with legal protection, or technological protection. If you give them both, they will use technological protection to exclude both fair use and ultimately transition into the public domain. Less and less of what is protected by copyright today will make it into the public domain eventually, because of technological protections, and fair use is already greatly restricted.
Your comments are classical FUD, claiming intangible advantages in order to gloss over tangible, concrete advantages.
I have seen no evidence whatsoever that current AMD chips are less reliable. The fact that AMD chips use a lower clock rate and generate less heat strongly suggest the opposite. In fact, reliability of processors does not seem to be a significant factor in overall PC reliability at all: disk drives, fans, memory, motherboards, and ports all usually go first.
If Dell would ship AMDs, we'd buy them. Instead, they are shipping souped up versions of the Pentium 3 to their corporate customers because that's the only thing they can ship from Intel. I really wonder whether the cosy relationships between, say, Dell and Intel, are merely friendly or whether there are some other arrangements...
64bit is hugely important, but the Itanium is a big gamble because of its architecture. An x86 architecture with 64bit extensions makes a lot of sense because it makes it easy to extend existing code generators to it. But the Itanium architecture requires code generators to be completely rewritten, and writing code generators for Itanium is a lot harder than writing code generators for x86. For practical purposes, you are probably only going to see C, C++, and maybe Java for some time to come.
If AMD managed to release their x86 with 64bit extensions in 2002, Intel would be big trouble. Too bad that they missed their targte again.
Slashdot Mirror
You can't rely on people remembering to convert units--they will make these mistakes. The problem is that the US hasn't converted to the metric system, and that NASA software apparently does not use type systems and data files containing units throughout. Those aren't stupid mistakes, they are on-going, deep-rooted problems, and they will cause more crashes, guaranteed.
The problem there wasn't the fact that people used wrong units in that one case. The problem was that (1) the US hasn't standardized on the metric system along with the rest of the world, and (2) that the NASA engineers didn't have software engineering procedures in place that required the presence of units on all data. Those are on-going, deep-rooted problems, and they are going to cause crashes and other problems over and over again until they get addressed.
I stopped using them years ago, both because of their handling of packages and because of their use of digital signature pads (which leave you with no recourse when they claim that they have your signature). I found Fedex and DHL to be considerably better.
Here is a random guess at a scenario: someone dropped something or the detector was filled to quickly. The implosion of the first detector caused a chain reaction and caused nearby detectors to implode as well. You have to expect that these kinds of accidents happen.
I suspect that the people who built the device simply didn't expect a chain reaction of implosions. Maybe one can argue in hindsight that they "should have" thought of it, but it's not like people regularly build things that have thousands of vacuum tubes deep under water.
What would be stupid is if they anticipated the possibility of a chain reaction of implosions and decided "oh, we just aren't going to drop anything accidentally". We'll have to see whether anything like that eventually comes out. Until then, I'd hold my judgement.
You can bet that any intermediate would try to take their cut--the "web master" would only get a tiny fraction of that if anything at all. Besides, such a flat pricing model is too expensive for some sites and too cheap for other.
We have a free market that decides these things. I'm all for offering support for micropayments, but a one-size-fits-all approach just doesn't appeal to me.
The language is clearly not what makes Java interesting--it's a conservative, somewhat tedious language. The libraries are quite good. But the runtime and its specification what makes Java really interesting from a systems point of view because it offers
- a well-specified, complete reflection interface.
- a well-specified, complete interface for dynamic code generation.
- a well-specified set of interfaces to the garbage collector.
- complete specification of what operations must throw what exceptions under what conditions.
- complete specifications of both statically typed and dynamically typed operations (in particular, numbers behave with predictable efficiency).
- implementations that actually reliably perform cross-compilation-unit inlining and other dynamic optimizations.
This makes it straightforward to implement bullet-proof and portable code walkers, debuggers, inspectors, novel efficient object systems, code instrumentation systems, transparent persistence and transparent remote objects, and lots more.Very true. And we'll just have to disagree on whether that was actually a good design decision. I think history will tell on this one ;-)
If you're going to critique Lisp in this way, be specific.
I'm not sure what you are responding to but it isn't anything I wrote. I do believe that CL has many problems, but CL is not the same as Lisp.
Vague and general insults without substance are not appropriate in this venue.
Are you kidding? This is Slashdot. I'll have to remember to add some next time.
It's not Lisp in general. Lisp integrates just fine with lots of environments. Lisp can integrate very well with UNIX if you let it (Elk Scheme and Bigloo are an excellent examples). And traditional Lisp implementations had everything from the assembler on up built-in and written in Lisp.
I think many of the people who developed CommonLisp and the Lisp machine just had a deep disdain for anything UNIX-related and therefore couldn't care less whether CommonLisp integrated well with UNIX or the kinds of things people were doing on UNIX. Just read the UNIX Hater's Handbook, contributed to by many vocal Lisp users in the the 1980's. As a result, CommonLisp has endless provisions allowing for pathname syntax on TENEX or oddball byte sizes, but few of the things that make systems like Perl, Python, or even Java so useful on UNIX and Windows. Other essential facilities didn't make it into the standard probably because many CL vendors thought they could use essential proprietary functionality as a way of binding users to their product.
I hope future Lisp implementations will learn from these past mistakes. CMU CommonLisp, in my opinion one of the best implementations around right now, might do well to just forget going for ANSI CL compatibility and instead come up with a more useful, more complete, and more streamlined feature set.
But the biggest problem with XP is its rampant commercialism. Windows, other Microsoft applications, and third party applications constantly bug you for personal information, registration information, etc. And who knows what information it's sending out behind my back. And I already spent about $100 on third party utilities.
Altogether, XP is something I could do without: it runs on applications I want to run, and the software I need to run on it is not particularly high quality. The only reason I have it is because Microsoft has managed to monopolize the market so much that there are applications you simply have to use in business and that only run on Windows. Yuck.
Having your name on the patent doesn't entitle you to anything. Most inventors never see a dime from the royaltees on their patents--it all goes to the assignee. If the school has an enlightened policy and if they actually own the patent, they may give students and researchers a cut of the royalties, but even then, they are not under any obligation to be fair about it--they might well decide only to reward professors and postdocs, no matter who is listed as co-inventor. If the research was sponsored by a company, often, none of the inventors sees any money beyond the grant.
It doesn't matter whose name is on the patent--the patent needs to be assigned to the school or the organization sponsoring the research anyway. Some schools have fairly liberal rewards for patents while others don't, but the actual rights in the patent will in any case not remain with the researcher. If the research was paid for by public funds, as most biomedical research is, the public should expect (though in these times doesn't always get) the rights to any invention--that is, it should be placed in the public domain.
Well, on the iPaq, you can actually compare this on the same hardware: I find X11 runs better than WinCE (in addition to being more robust and easier to program).
I haven't been able to do a side-by-side comparison with Qt/Embedded, but according to Troll Tech's own specs, it seems to require more resources than X11.
At least the Sharp has a USB port
The Sharp hardware is nice. Let's hope they'll see the light and support a completely standard Linux environment.
Well, if you use X11 on it, you effectively lose all the built-in apps, which want to write directly to the screen buffer. That, or you have to do a lot of really hard work on X11 to make it integrate with Qt/Embedded. I think getting a different Linux PDA is a whole lot easier.
I run VNC, MP3, video streams, games, and backups over 802.11b. If wireless gets faster, that's nice. But I don't really have a desparate need for it, and I suspect few other peopled do either.
I'll stick with my Palm as an organizer, and with the iPaq using the Familiar distribution for developing special purpose handheld software. You can pooh-pooh X11 all you want, it works well, it uses no more resources than QTE, it's free, and it manages to run Gtk+, FLTK, wxWindows, and Qt, all on the same screen.
I think they are as relevant today as they were five years ago. If you stick with the CommonLisp standard, you only get very limited functionality. If you use the full spectrum of functionality available in any particular implementation, you make yourself a member of a tiny user community and dependent on some small company. Calling both CommonLisp and the vendor variants collectively "Lisp" is as misleading as it would be to refer to C#, Java, and C++ collectively as "C".
Compare the CommonLisp situation with, say, Java. If you write applications in Sun Java, you are writing for a platform with a huge user community, a vast set of libraries with detailed documentation, excellent performance, lots of dynamic and reflective features, and negligible licensing costs (too bad about the syntax, though). If Franz or some other vendor managed to do the same Job with their CommonLisp variant as Sun did with Java, I'd switch back in an instant and would have no problem using the system commercially.
High performance Lisp systems which are well integrated with their host environments are readily available at all price points.
Well, I've used Franz, CMU CL, AKCL, GCL, CLISP, Bigloo, and PLT. I have also checked the implementations at lisp.org every now and then. Which system are you thinking of?
Bromley and Lamson's "Lisp Lore" most certainly does talk about source code debugging.
No contradiction there. My claim was that source level debugging didn't make it out to customers until the late 1980's. Bromley/Lamson came out in 1987. I was referring to Bromley's Lisp Lore, which came out in 1986 and AFAIK doesn't talk about it. With Genera 8, the Lisp machine became a much better system, with better debugging support and a better GUI, but it was too late.
I agree that if free software is created by the same people intending to support it, that is a problem.
But free software doesn't disable free market mechanisms. If RedHat ships software that sucks in order to drive up support costs, you don't have to use their software--you can pay someone to create the kind of software you like (perhaps as part of a collective bidding process).
So, overall, that's not an argument against free software in general, or against the ability to have an efficient market built around free software, it's an argument about one particular broken way of creating free software.
And what exactly is wrong with that? Assuming for the sake of argument that Word was the only game in town, you would have paid handsomely for upgrades from Word 3.0 to Word 97 give how lousy early versions of Word were. But between Office 97 and Office 2000, there were almost no enhancements anybody wanted. Microsoft manages to force companies to pay excessive amounts of money for upgrades they don't need and they don't want--this is not an efficient free market at work.
Dunno if my point comes accross, but 'small apps' don't net money in the service/support arena, only in initial sales. If the 'small app' is free, then...
People who need a small app pay for it initially, and then it becomes free. The programmer who created it gets paid, and that's it--there are no further profits. Why should there be? In an efficient market, the price of a product represents the cost necessary to produce it. If the small app doesn't quite do what you want, you can hire another programmer to enhance it and pay for it; the amount of money involved is so small that this doesn't really fall prey to the tragedy of the commons, as real-world experience with open source software shows.
Sure you can: with consulting, contract work, training, and documentation. Such a software economy has many advantages: it encourages innovation because the same software isn't created and marketed by zillions of companies, it speeds up innovation because people can build on existing software, it increases efficiency because end users pay for a feature only once rather than over and over again with each upgrade, and it means that programmers get to do more interesting work and offers them a chance to work much more as independent economic agents.
Of course, you cannot built Microsoft or Oracle-style empires in such a software economy. You also cannot have stock prices that go through the roof. Instead, you reward an hour of work with an hour's worth of pay. Opening up software brings it back from being a plaything of corporate megalomaniacs and monopolists to individual craftsmenship. That is, it brings individual skill and free enterprise back into the equation.
And open source is at a grave disadvantage here: when Microsoft violates the GPL, nobody will know about it because it is hidden in gigabytes of messy binaries. But when Apache or the Linux kernel steps on someone's toes, everybody knows about it right away because the source code is open and widely read.
I don't have a solution for this problem other than that we need to become more active politically: open source software should not be at this disadvantage. But until the laws are fixed, decisions like Cox's, will be both rational and increasingly common. Stopgap technological measures, such as anonymous posting of such information, may help in the meanwhile, but they are far from perfect, both because they don't actually remove the legal liability and because they make development unnecessarily cumbersome.
The people I asked around the MIT AI lab didn't seem to know about it at the time, and as a Lisp machine user for half a dozen years, I never came across it in the voluminous documentation. I don't think "Lisp Lore" mentioned it either. I think if you look at how you say this was "documented", you can figure out yourself why nobody knew about it. Compare this with Smalltalk-80, which already had rich, obvious, powerful source level debugging around 1980 and presented the facility in an obvious, easy-to-use way. Overall, I think the Lisp machine had a decent development and debugging environment, but I personally wouldn't call it ground-breaking.
While I found the Newquist book to be a fun read, it gets a large number of otherwise easily verifiable facts wrong. I certainly hope you did not reach your conclusions using only that book as a reference!
Actually, my conclusions are based on my own experience: I was a Lisp machine user for half a dozen years and a CommonLisp user for a dozen years. I tried hard to introduce CommonLisp at several research labs and companies, but eventually gave up, for the reasons that I mentioned: the implementations cost too much and writing code that was both portable and efficient was a lot of work, negating much of the productivity advantage. Furthermore, the Windows and UNIX versions of CL never really seemed to integrate well with their environment.
I consider it a rather sad history because CommonLisp was quite a ways towards being a really great language and environment. Fortunately, many of its ideas live on in a variety of modern languages. And maybe, just maybe, CMU CL or some variant of Scheme will pick up the torch: a good open-source implementation that avoids some of the ANSI CL hair and integrates well with its environment might get picked up again by more users.
Seems like you are confirming what I'm saying: the Lisp machine did not have source level debugging until Genera 8. Whether it was hidden somewhere in the source code where your customers couldn't get at it hardly matters.
I didn't claim that Lisp caused the problem. I claimed that poor business decisions, i.e., delivering an overly expensive niche market product, killed Symbolics and LMI and gave Lisp a reputation for being expensive and complex, something you, again, seem to confirm.
You are still operating under the mistaken assumption that Lisp has become marginalized because I or others have an irrational dislike of it. Quite to the contrary. I think Lisp is the greatest thing since sliced bread. That is why it has been so painful to see its decline over the last two decades, a decline I attribute to greedy and poor management at various Lisp vendors and a poorly conceived standard for CommonLisp.
I hope a new generation of researchers and programmers will learn from this history and that over this decade, Lisp will make a comeback. But that's why it is important to understand what went wrong in the first place.
Another interesting link about the history of Lisp and the Lisp machine is here, which basically reaches the same conclusion that I did.
Oh, and if you would like to experience a little more the sensitivity and humility with which many in the Lisp machine community have criticized other systems, just take a look here.
Arguably, copyright holders who encrypt their works aren't living up to their side of the deal. If copyright holders don't live up to their side of the deal, why should society live up to its side of the deal?
I understand why the Europeans ultimately gave in to industry demands, and this is not a simple decision. But I think in the long run, this is a mistake. Content creators should choose between either free and open distribution coupled with legal protection, or technological protection. If you give them both, they will use technological protection to exclude both fair use and ultimately transition into the public domain. Less and less of what is protected by copyright today will make it into the public domain eventually, because of technological protections, and fair use is already greatly restricted.
I have seen no evidence whatsoever that current AMD chips are less reliable. The fact that AMD chips use a lower clock rate and generate less heat strongly suggest the opposite. In fact, reliability of processors does not seem to be a significant factor in overall PC reliability at all: disk drives, fans, memory, motherboards, and ports all usually go first.
If Dell would ship AMDs, we'd buy them. Instead, they are shipping souped up versions of the Pentium 3 to their corporate customers because that's the only thing they can ship from Intel. I really wonder whether the cosy relationships between, say, Dell and Intel, are merely friendly or whether there are some other arrangements...
If AMD managed to release their x86 with 64bit extensions in 2002, Intel would be big trouble. Too bad that they missed their targte again.