The Lisp Machine was the first commercially available workstation: the first machine you could buy that had such revolutionary features as high-res bitmapped display console, mouse, window system, high-powered processor, large disk, huge address space, and local area network.
That's not the history I remember. The Xerox Alto started being distributed outside Xerox in 1974. The VAX 11/780 came out in 1978. The CADR, I believe, came out in 1979, and LMI Inc. was founded in 1981, the same year as the Apollo. But if I got my years wrong, maybe you can relate the years as you remember them.
The cost was originally around $70,000 per seat, which was considered quite reasonable. When other workstations were invented and some of the costs came down, the pricing was reduced competitively.
Even in the late 1980's, you could get a Sun workstation with color screen for a few thousand dollars, while a black-and-white Lisp machine with similar performance would set you back tens of thousands of dollars.
[Lisp machines] supported Lisp, and also many other languages (such as FORTRAN and ADA), and did most certainly have source-level debugging since the beginning.
Not for a modern view of source level debugging. Until Genera 8, the Symbolics debugger would still show you an instruction backtrace for compiled Lisp code, and for interpreted code might give you an S-expression if you asked really nicely. None of that was tied to the source code in a way that any modern IDE does, or in the way that even GNU Emacs did at the time for C. (As an aside, Symbolics didn't use real overlapping windows as late as the late 1980's because of the oddball ways window contents were aliased into rectangular arrays.)
Many of the techniques that are common in today's advanced programming and debugging environments were pioneered on the Lisp Machine, and there are many useful debugging features that are still not available in today's C/C++/Java environments.
I think Smalltalk-80 has a much bigger claim to that than the Lisp Machine. In retrospect, it's just amazing to me how far ahead the Smalltalk-80 system was (you can try it out for yourself: go to www.squeak.org).
If you can name any Lisp machine debugging features absent from modern Java IDEs, I'd certainly like to know about them.
It sure as hell was not due to a lack of features!
You make the assumption that "more features" is necessarily better. That is probably the most concise way in which one could state the failure of the Lisp machine and of CommonLisp. In fact, good design requires careful tradeoffs and restraint. It's a shame that such more carefully designed Lisp systems didn't make it into the real world until after Lisp had already acquired a reputation for being overly complex and resource intensive.
I know a lot of these experts you're talking about personally. Are they ignorant of CL and its strengths? No. But are they independently wealthy? Also no. So what happens? They have to get a job where people are offering. Would they have preferred Lisp jobs? In most cases I can think of, sure, absolutely.
Well, all the ex-MIT hackers that I know (myself included) stopped using CommonLisp because it was too hard to get our work done with it. Our employers would have been happy to keep paying for MCL or Franz or whatever, and there is always CMU CL.
The fact is that many well-meaning people make arguments just like you're making, that you can't make money with Lisp. And that becomes a self-fulfilling prophecy
I never made any argument about whether you can or cannot make money with Lisp, and that issue is of no interest to many of my projects (I'm a researcher).
Furthermore, the argument that CommonLisp isn't being used because management doesn't know any better fails because CommonLisp is conspicuously absent in the large fraction of projects where the opinion of PHBs usually doesn't matter: free software and open source projects.
Did they dislike Lisp? Nope.
Who ever said anything about "disliking Lisp"? The subject of this thread is "ANSI CL and the Lisp machine killed Lisp". In fact, I like Lisp a lot, and I think it's a shame that we don't have a better, more modern standard by now. Yale T, ISO Lisp, and Dylan all seemed like promising attempts, each in its own way.
I cannot really follow your rationale - it is all very fuzzy and subjective. Nobody forces you to like or use Common Lisp but don't spread such FUD to the people. Most of what you have written on "better" or on what in your sole opinion the ANSI CL Standard got wrong is absolutely subjective without any concrete argumentation.
Don't be silly. If this were "my sole opinion", lots of people would still be using CommonLisp and I'd be the lonely holdout not using it. Reality is that most experienced CommonLisp users have switched to Java or other languages by now, and they didn't do so out of ignorance.
ANSI CL never claimed to be an industrial-strength programming language. (Implementations might be, or claim to be, industrial-strength, but portability and industrial-strength are orthogonal concepts.)
I wasn't talking about what CL "claimed" to be but what it was actually being used for: large, real-world artificial intelligence systems. And it clearly wasn't all that good at the other areas: too messy for teaching and not well-enough integrated with UNIX for scripting.
Personally, I think it is a lot more important to have a portable object model than to have a portable networking interface.
That's kind of like saying that having a brain is a lot more important than a heart. Any modern programming system that wants to succeed needs to have both, as well as a lot of other things. ANSI CL failed to standardize those and many other important pieces of functionality.
As for the issues you mention on type-checking being non-portable, optimization and portability are nearly opposite directions. Different implementations (and different (optimize...) settings) will make different trade-offs. If you're spending the time to seriously optimize a program, you probably have gone past the point of worrying about your choice of platform.
Well, you may not think it mattered, but the simple fact is that lots of CommonLisp users have voted with their feet. I'm just telling you why I and most other people I know stopped using CL for anything big and important. I expect a good language standard to allow me to write programs that are both portable and predictably efficient, and a language standard that fails to do that is of no interest to me.
How can you reconcile your recommendation of Scheme with your condemnation of Common Lisp? The Scheme standard (R5RS) does not standardize type checking at all. Nor does it standardize multiprocessing, nor networking, nor the compiler interface, etc. There is greater variability between Scheme implementations then between Common Lisp implementations on these issues.
That's a valid question. My response is that I don't view Scheme and CommonLisp as covering the same ground. CommonLisp really tried to claim being an industrial-strength application development language, and I think it failed badly at that. Scheme, at least to me, is a variety of things that CommonLisp never really was: an extension language, a scripting language, a prototyping language, and a teaching language. At its chosen problem domains, Scheme is quite good.
Also, porting the code without worrying about efficiency, is usually trivial, even between different implementations on different platforms (assuming CLIM or some other standardized interface was used). This means that you instantly get working code, even though it may not be as fast as it was on the originally implementation.
I have to disagree with this. It is easy to port code that was intended to be portable, but once you put in all the hooks to make it efficient, it fails. Some CL implementations, for example, tolerate incorrect type declarations, while they lead to crashes or runtime errors on other systems. And what is "incorrect" may itself depend on the implementation.
Compare this with C, C++, etc. where porting between different machines, even with the same compiler vendor, is often quite tricky.
Yes, it is very easy to write C/C++ code that is completely unportable. Even worse, the source code contains no indication of the use of unportable constructs. This is a major problem with C/C++. However, unlike CommonLisp, it is also very easy to write C/C++ code that is both efficient and completely portable. I think that has contributed to making C/C++ so popular.
I also would like to know what you consider vague about the condition system. I've always considered it one of the strong points of the language and easily graspable.
The condition system itself is OK, but the standard leaves a lot of leeway to implementations of what exceptional conditions are actually detected and what their consequences are. And the CL standard still contains many undefined effects. The hope was that this would allow implementations to be more efficient, but that doesn't seem to have panned out.
I think Java is a lot better in this regard, specifying precisely what exceptions get thrown by what primitives, and the runtime cost is small. (Java got a little overly zealous with numerical exceptions, to the point where it unnecessarily affected efficiency, but that's being fixed.)
I also disagree with your statement that the ANSII Common Lisp standard is poorly written. I consider it to be a superb example of technical writing. I use it day-to-day as a reference when writing ANSI Common Lisp programs.
I wasn't referring to style (the prose is nice), but to content.
Altogether, I think CommonLisp has the right idea in terms of overall language functionality for an advanced language for rapid development and prototyping: Lisp syntax, macros, reflection, powerful object system, interactive development, dynamic modification of code, etc. But the ANSI CL standard just got too many practical issues wrong as far as I'm concerned. The right thing to have done would have been to start over and not accomodate the half-dozen or so vendors with their oddball interests. In fact, some such efforts were around in the early 1990s, but the existence of the ANSI CL standard never let them get off the ground, and I think ANSI CL gave Lisp such a bad name that eventually people just gave up on it. In fact, in many ways, systems like Java and Python are Lisp systems disguised carefully enough so as to not offend a Lisp-weary public.
CommonLisp and the Lisp Machine had lots of design problems and it is no surprise that they failed. But Lisp syntax is easy to comment and it's easy to learn--much easier than, say, Perl. Scheme and other Lisp implementations carry the torch, and Lisp syntax and semantics won't go away.
(Incidentally, 10000 lines in any programming language isn't a lot of code, so by your own admission, you don't really know Lisp very well.)
Lisp is great: a simply syntax, powerful semantics, and an extensible environment. Unfortunately, ANSI CL and the Lisp machine killed it. Why?
Lisp machines were expensive workstations that cost tens of thousands of dollars to deliver performance that, even at the time, could easily be had for a few thousand dollars. Contrary to popular claims, the programming environment has some serious limitations, including lack of source level debugging (eventually it got added, but only after the system had already fallen from grace). Those systems simply were not competitive and gave Lisp a reputation of requiring gold plated hardware, carried over into hugely expensive development and runtime licenses. And the use of those machines also kept Lisp from ever integrating well into mainstream environments.
An even bigger problem with Lisp was ANSI CommonLisp. ANSI CommonLisp failed to standardize some really important functionality, like threads, reflection, and networking. What it did specify it specified poorly: the meaning of type declarations and conditions (exceptions) is still vague. The upshot is that CommonLisp programs are a pain to port and require careful hand-tuning for each implementation. A program that runs fast on one implementation runs like molasses on another.
The most frequently named "issues" with Lisp never were issues as far as I can tell. People who put up with Perl syntax should have no problem putting up with Lisp syntax. And performance and resource requirements of Lisp implementations are small compared to Java or even modern scripting languages.
So, where is Lisp going? CMU CommonLisp is trying valiantly to maintain CommonLisp functionality and enhance it, but it is hampered by being based on a poorly written Lisp standard. Python actually gives you most of the power and convenience of Lisp but integrates much more nicely with its environment; Python's big drawback is the lack of good native code compilation. Java includes many Lisp features (Java was designed by people with a lot of Lisp experience) and it specifies reflection, runtime code generation, and exception handling much better than CommonLisp (too bad about the syntax, though). Scheme is probably the best variety of Lisp these days, and there are some really good implementations out there (Bigloo and PLT Scheme being some of them; Bigloo and Cygnus's Scheme compilers even compile to the JVM if you like). And the ML series of languages (SML, OCAML) give you most of the convenience of Lisp with full type checking and no type declarations.
Lisp continues to live in many forms, despite the Lisp machine and despite ANSI CommonLisp.
Re:IDE - Editor or round trip engineering tool?
on
Java IDEs?
·
· Score: 2
By generating UML a developer can quickly and efficiently offload a whole heap of information in a way other developers can pick up quickly even if the original designer isn't about.
But generated UML is not the same as hand-crafted UML. Generated UML is a complete representation of the system, like a circuit diagram that shows every transistor; it doesn't contain any information about what the designer had in mind and it contains huge amounts of irrelevant detail. Hand-crafted UML, on the other hand, is deliberately incomplete and focusses on the important stuff. It expresses what the designer actually was trying to do without the distraction of unimportant low-level detail.
In my experience, hand-crafted UML is more useful to the reader. It's also more useful to the designer because the exercise of creating it forces some useful introspection that is well worth the time and effort.
Re:IDE - Editor or round trip engineering tool?
on
Java IDEs?
·
· Score: 3, Insightful
Using an automatic tool to generate/maintain UML is a bad idea. UML should represent stuff in your head, stuff that you consider important. The exercise of drawing it by hand is an important part of the UML design process (you are supposed to remember all those methods; if you can't, your system should probably be simplified). And too much detail is just as bad as too little detail.
In practice, I have also found the various "enhanced" IDEs (with support for roundtrip UML or refactoring) to be too sluggish. I prefer a fast editor, a fast compiler, and some simple linking between error messages and source code any time
Before copyrights, we got Mozart and Bach. After copyrights, we get Britney Spears and N'Sync. I think the argument that copyrights are necessary in order to create great music are a little thin...
The IT managers probably don't have a clue as to whether anybody is going to deploy Linux next year--those decisions get made elsewhere. Many of them are already running "critical services" on Linux and don't even know about it.
This isn't new. 10-15 years ago, IT managers didn't have a clue about PCs. They would have cheerfully told you that they had no plans to deploy PCs. Meanwhile, people were buying and installing PCs everywhere.
IT managers often seem to live in some stratospheric haze of PowerPoint presentations, corporate sales representatives, buzzwords, and grandiose strategies. Don't get me wrong: they do serve important functions: getting a budget, personnel, short-term strategies, and all that. But long-term planning and change is largely out of their control--long term change just happens for a variety of unpredictable and idiosyncratic reasons.
The space shuttles are already overdesigned, dangerous, fairly useless, and overly expensive pieces of equipment; why would anybody want to buy them at this point? Now, privatizing the ISS might be worth thinking about: it, too, is a white elephant, but the waste and cost has already been sunk into lifting those useless parts into orbit. Now that they are there, a commercial enterprise might figure out how to do something useful with it (even if it is just a space amusement park).
I think privatizing significant parts of NASA doesn't make sense at all at this point. But if people are going to attempt that, they'll have to come up with a better proposition than this. The time to privatize is before the design begins, and you have to make sure that the private entity actually bears the launch costs: only then will rational self-interest result in cost-effective designs.
I hope not. The best source for hydrogen is solar energy. If you are planning on producing hydrogen from methane, you might as well just use the methane directly.
Hydrogen isn't just better, it's essentially the only choice when it comes to storing and transporting solar energy on a large scale. The idea is to generate hydrogen in desert regions and ship it to where it is used. Furthermore, hydrogen can be generated using solar energy in a variety of ways, and the energy expended on that wouldn't be useful for much else.
I hadn't heard of the "Familiar" Linux distribution which sounds like a great step in the right direction...
If you don't have any experience with X11 on handhelds, what basis do you have for making all these claims about its supposed inefficiency?
I've used X11 on 20MHz 386 machines with 4Mbytes of RAM, on 68020 machines, on an AgendaVR3, and on an iPaq. Trust me, it's fast enough. And Qt/Embedded's resource requirements are no less than X11.
"Small is beautiful"? These people are programming a machine with a 200MHz RISC chip with 32Mbytes of memory. That isn't small, that's high-end desk-top performance of a few years ago.
WierdX is nice, but it isn't a usable X11 implementation. The Linux X11 server for handhelds is smaller than Qt/Embedded, is blindingly fast, and supports features such as ClearType-like sub-pixel rendering.
As for Qt, there is almost no handheld software written in it. Almost all handheld software for Linux is written using FLTK. And many desktop applications could be adapted to handhelds by simplifying their existing user interfaces within their toolkit--much simpler than a rewrite using a different toolkit. Commercial developers are not going to line up to rewrite their software for Qt.
As for consistency, forcing everybody to use the same toolkit is neither necessary nor sufficient to achieve consistency.
Did you even read the message you are responding to? X11 runs fine on the AgendaVR (a 66MHz MIPS) and the iPaq (a 200MHz ARM). It was developed on and for low-end DEC workstations with considerably less power. I won't repeat the other arguments.
The hardware is nice, although starting to show its age (faster ARMs are around the corner). I think the choice of Qt/Embedded for the GUI is a big mistake, however.
Linux PDAs won't take over the consumer market from Palm, but they are good platforms for vertical and custom software (medical, scientific, legal, etc.). But people who write that kind of software already have languages, environments, and toolkits for their domains, and those languages and toolkits are usually not Java, C++, or Qt. X11 would allow applications created in different environments to co-exist, but Qt/Embedded forces everybody to use Qt.
I hope Sharp will put X11 on the device. They can keep their Qt applications by switching to Qt/X11 for their applications. If they don't base the UI on X11, I think they are going to miss their target market.
(In case you want to bring up the "performance" argument for using an "embedded toolkit", a 200MHz ARM is the equivalent of a desktop machine from a few years ago, machines that ran X11 with no problems. X11 was actually developed on and for machines less powerful than today's low-end Palms.)
Now, people who either don't want to have their actions documented or who like to profit even more from images and ideas that really belong to the public can use the excuse of combatting terrorism to exclude cameras from even more places. Well, compared to the other things terrorism has been used as an excuse for (vastly expanded police powers, lots of layoffs and business failures, almost complete abolition of civil rights for immigrants), I suppose this one is still fairly minor.
The ARM CPU architecture is patented and ARM has sucessfully defended [arm.com] their architecture against IP theft in the past.
That's a gross mischaracterization. First, ARM has had a legal victory, but which claim that was actually based on was never decided. Concluding from that that ARM has "successfully defended" any particular aspect, or the entirety, of their architecture is just wrong.
Second, there is no indication that any form of "IP theft" has occurred. Creating a core from scratch that works like the ARM chip is entirely legal in and of itself.
As for you "microwave bacon cooker" example, you can legally make something that doesn't infringe the patent, no more and no less. Since the basic technology for microwave bacon cooking has been known for a while, their patent may not protect anything particularly important, and you may well be able to copy most of their engineering effort.
On the one hand, this allows people to lessen their dependence on proprietary operating systems. On the other hand, it means that some already proprietary formats become even more deeply entrenched as there is less incentive for anyone to create and use alternatives.
On balance, I'd say: don't use it unless you really have a very compelling need. View MS Office documents in StarOffice or AbiWord and submit bug reports for any problems you find; that's how those programs get better. As for Quicktime, complain to the web site using it and ask them to use an open format instead (in fact, do that whether or not you actually have a Quicktime viewer).
I don't see much purpose to the ISS. We should concentrate on robotic missions for now: they yield much more information per dollar spent. NASA seemed to think so as well; the ISS seems to have mostly been pushed through for political reasons, not for scientific ones. (Of course, I still prefer the ISS to bombs, but that's another matter.)
Oh, I agree: Apple is fully responsible for this, and programmers should get this right if they use the Bourne shell.
But if a system is designed in such a way that people frequently make a certain mistake, and if it is easy to change the system, without limiting its functionality, to keep people from making that mistake, then the system has a design flaw. This applies to the Bourne shell, and that's presumably why its successor at Bell Labs doesn't behave this way anymore.
As for Apple, they should have been using decent package management. If they do need to script, they should have been using a scripting language that gets this right (Perl, Python, etc.). As a last resort, they should at least know their tools.
Slashdot Mirror
That's not the history I remember. The Xerox Alto started being distributed outside Xerox in 1974. The VAX 11/780 came out in 1978. The CADR, I believe, came out in 1979, and LMI Inc. was founded in 1981, the same year as the Apollo. But if I got my years wrong, maybe you can relate the years as you remember them.
The cost was originally around $70,000 per seat, which was considered quite reasonable. When other workstations were invented and some of the costs came down, the pricing was reduced competitively.
Even in the late 1980's, you could get a Sun workstation with color screen for a few thousand dollars, while a black-and-white Lisp machine with similar performance would set you back tens of thousands of dollars.
[Lisp machines] supported Lisp, and also many other languages (such as FORTRAN and ADA), and did most certainly have source-level debugging since the beginning.
Not for a modern view of source level debugging. Until Genera 8, the Symbolics debugger would still show you an instruction backtrace for compiled Lisp code, and for interpreted code might give you an S-expression if you asked really nicely. None of that was tied to the source code in a way that any modern IDE does, or in the way that even GNU Emacs did at the time for C. (As an aside, Symbolics didn't use real overlapping windows as late as the late 1980's because of the oddball ways window contents were aliased into rectangular arrays.)
Many of the techniques that are common in today's advanced programming and debugging environments were pioneered on the Lisp Machine, and there are many useful debugging features that are still not available in today's C/C++/Java environments.
I think Smalltalk-80 has a much bigger claim to that than the Lisp Machine. In retrospect, it's just amazing to me how far ahead the Smalltalk-80 system was (you can try it out for yourself: go to www.squeak.org).
If you can name any Lisp machine debugging features absent from modern Java IDEs, I'd certainly like to know about them.
It sure as hell was not due to a lack of features!
You make the assumption that "more features" is necessarily better. That is probably the most concise way in which one could state the failure of the Lisp machine and of CommonLisp. In fact, good design requires careful tradeoffs and restraint. It's a shame that such more carefully designed Lisp systems didn't make it into the real world until after Lisp had already acquired a reputation for being overly complex and resource intensive.
Well, all the ex-MIT hackers that I know (myself included) stopped using CommonLisp because it was too hard to get our work done with it. Our employers would have been happy to keep paying for MCL or Franz or whatever, and there is always CMU CL.
The fact is that many well-meaning people make arguments just like you're making, that you can't make money with Lisp. And that becomes a self-fulfilling prophecy
I never made any argument about whether you can or cannot make money with Lisp, and that issue is of no interest to many of my projects (I'm a researcher).
Furthermore, the argument that CommonLisp isn't being used because management doesn't know any better fails because CommonLisp is conspicuously absent in the large fraction of projects where the opinion of PHBs usually doesn't matter: free software and open source projects.
Did they dislike Lisp? Nope.
Who ever said anything about "disliking Lisp"? The subject of this thread is "ANSI CL and the Lisp machine killed Lisp". In fact, I like Lisp a lot, and I think it's a shame that we don't have a better, more modern standard by now. Yale T, ISO Lisp, and Dylan all seemed like promising attempts, each in its own way.
Don't be silly. If this were "my sole opinion", lots of people would still be using CommonLisp and I'd be the lonely holdout not using it. Reality is that most experienced CommonLisp users have switched to Java or other languages by now, and they didn't do so out of ignorance.
I wasn't talking about what CL "claimed" to be but what it was actually being used for: large, real-world artificial intelligence systems. And it clearly wasn't all that good at the other areas: too messy for teaching and not well-enough integrated with UNIX for scripting.
Personally, I think it is a lot more important to have a portable object model than to have a portable networking interface.
That's kind of like saying that having a brain is a lot more important than a heart. Any modern programming system that wants to succeed needs to have both, as well as a lot of other things. ANSI CL failed to standardize those and many other important pieces of functionality.
As for the issues you mention on type-checking being non-portable, optimization and portability are nearly opposite directions. Different implementations (and different (optimize ...) settings) will make different trade-offs. If you're spending the time to seriously optimize a program, you probably have gone past the point of worrying about your choice of platform.
Well, you may not think it mattered, but the simple fact is that lots of CommonLisp users have voted with their feet. I'm just telling you why I and most other people I know stopped using CL for anything big and important. I expect a good language standard to allow me to write programs that are both portable and predictably efficient, and a language standard that fails to do that is of no interest to me.
That's a valid question. My response is that I don't view Scheme and CommonLisp as covering the same ground. CommonLisp really tried to claim being an industrial-strength application development language, and I think it failed badly at that. Scheme, at least to me, is a variety of things that CommonLisp never really was: an extension language, a scripting language, a prototyping language, and a teaching language. At its chosen problem domains, Scheme is quite good.
Also, porting the code without worrying about efficiency, is usually trivial, even between different implementations on different platforms (assuming CLIM or some other standardized interface was used). This means that you instantly get working code, even though it may not be as fast as it was on the originally implementation.
I have to disagree with this. It is easy to port code that was intended to be portable, but once you put in all the hooks to make it efficient, it fails. Some CL implementations, for example, tolerate incorrect type declarations, while they lead to crashes or runtime errors on other systems. And what is "incorrect" may itself depend on the implementation.
Compare this with C, C++, etc. where porting between different machines, even with the same compiler vendor, is often quite tricky.
Yes, it is very easy to write C/C++ code that is completely unportable. Even worse, the source code contains no indication of the use of unportable constructs. This is a major problem with C/C++. However, unlike CommonLisp, it is also very easy to write C/C++ code that is both efficient and completely portable. I think that has contributed to making C/C++ so popular.
I also would like to know what you consider vague about the condition system. I've always considered it one of the strong points of the language and easily graspable.
The condition system itself is OK, but the standard leaves a lot of leeway to implementations of what exceptional conditions are actually detected and what their consequences are. And the CL standard still contains many undefined effects. The hope was that this would allow implementations to be more efficient, but that doesn't seem to have panned out.
I think Java is a lot better in this regard, specifying precisely what exceptions get thrown by what primitives, and the runtime cost is small. (Java got a little overly zealous with numerical exceptions, to the point where it unnecessarily affected efficiency, but that's being fixed.)
I also disagree with your statement that the ANSII Common Lisp standard is poorly written. I consider it to be a superb example of technical writing. I use it day-to-day as a reference when writing ANSI Common Lisp programs.
I wasn't referring to style (the prose is nice), but to content.
Altogether, I think CommonLisp has the right idea in terms of overall language functionality for an advanced language for rapid development and prototyping: Lisp syntax, macros, reflection, powerful object system, interactive development, dynamic modification of code, etc. But the ANSI CL standard just got too many practical issues wrong as far as I'm concerned. The right thing to have done would have been to start over and not accomodate the half-dozen or so vendors with their oddball interests. In fact, some such efforts were around in the early 1990s, but the existence of the ANSI CL standard never let them get off the ground, and I think ANSI CL gave Lisp such a bad name that eventually people just gave up on it. In fact, in many ways, systems like Java and Python are Lisp systems disguised carefully enough so as to not offend a Lisp-weary public.
(Incidentally, 10000 lines in any programming language isn't a lot of code, so by your own admission, you don't really know Lisp very well.)
Lisp machines were expensive workstations that cost tens of thousands of dollars to deliver performance that, even at the time, could easily be had for a few thousand dollars. Contrary to popular claims, the programming environment has some serious limitations, including lack of source level debugging (eventually it got added, but only after the system had already fallen from grace). Those systems simply were not competitive and gave Lisp a reputation of requiring gold plated hardware, carried over into hugely expensive development and runtime licenses. And the use of those machines also kept Lisp from ever integrating well into mainstream environments.
An even bigger problem with Lisp was ANSI CommonLisp. ANSI CommonLisp failed to standardize some really important functionality, like threads, reflection, and networking. What it did specify it specified poorly: the meaning of type declarations and conditions (exceptions) is still vague. The upshot is that CommonLisp programs are a pain to port and require careful hand-tuning for each implementation. A program that runs fast on one implementation runs like molasses on another.
The most frequently named "issues" with Lisp never were issues as far as I can tell. People who put up with Perl syntax should have no problem putting up with Lisp syntax. And performance and resource requirements of Lisp implementations are small compared to Java or even modern scripting languages.
So, where is Lisp going? CMU CommonLisp is trying valiantly to maintain CommonLisp functionality and enhance it, but it is hampered by being based on a poorly written Lisp standard. Python actually gives you most of the power and convenience of Lisp but integrates much more nicely with its environment; Python's big drawback is the lack of good native code compilation. Java includes many Lisp features (Java was designed by people with a lot of Lisp experience) and it specifies reflection, runtime code generation, and exception handling much better than CommonLisp (too bad about the syntax, though). Scheme is probably the best variety of Lisp these days, and there are some really good implementations out there (Bigloo and PLT Scheme being some of them; Bigloo and Cygnus's Scheme compilers even compile to the JVM if you like). And the ML series of languages (SML, OCAML) give you most of the convenience of Lisp with full type checking and no type declarations.
Lisp continues to live in many forms, despite the Lisp machine and despite ANSI CommonLisp.
But generated UML is not the same as hand-crafted UML. Generated UML is a complete representation of the system, like a circuit diagram that shows every transistor; it doesn't contain any information about what the designer had in mind and it contains huge amounts of irrelevant detail. Hand-crafted UML, on the other hand, is deliberately incomplete and focusses on the important stuff. It expresses what the designer actually was trying to do without the distraction of unimportant low-level detail.
In my experience, hand-crafted UML is more useful to the reader. It's also more useful to the designer because the exercise of creating it forces some useful introspection that is well worth the time and effort.
In practice, I have also found the various "enhanced" IDEs (with support for roundtrip UML or refactoring) to be too sluggish. I prefer a fast editor, a fast compiler, and some simple linking between error messages and source code any time
Before copyrights, we got Mozart and Bach. After copyrights, we get Britney Spears and N'Sync. I think the argument that copyrights are necessary in order to create great music are a little thin...
This isn't new. 10-15 years ago, IT managers didn't have a clue about PCs. They would have cheerfully told you that they had no plans to deploy PCs. Meanwhile, people were buying and installing PCs everywhere.
IT managers often seem to live in some stratospheric haze of PowerPoint presentations, corporate sales representatives, buzzwords, and grandiose strategies. Don't get me wrong: they do serve important functions: getting a budget, personnel, short-term strategies, and all that. But long-term planning and change is largely out of their control--long term change just happens for a variety of unpredictable and idiosyncratic reasons.
I think privatizing significant parts of NASA doesn't make sense at all at this point. But if people are going to attempt that, they'll have to come up with a better proposition than this. The time to privatize is before the design begins, and you have to make sure that the private entity actually bears the launch costs: only then will rational self-interest result in cost-effective designs.
I hope not. The best source for hydrogen is solar energy. If you are planning on producing hydrogen from methane, you might as well just use the methane directly.
Hydrogen isn't just better, it's essentially the only choice when it comes to storing and transporting solar energy on a large scale. The idea is to generate hydrogen in desert regions and ship it to where it is used. Furthermore, hydrogen can be generated using solar energy in a variety of ways, and the energy expended on that wouldn't be useful for much else.
If you don't have any experience with X11 on handhelds, what basis do you have for making all these claims about its supposed inefficiency?
I've used X11 on 20MHz 386 machines with 4Mbytes of RAM, on 68020 machines, on an AgendaVR3, and on an iPaq. Trust me, it's fast enough. And Qt/Embedded's resource requirements are no less than X11.
"Small is beautiful"? These people are programming a machine with a 200MHz RISC chip with 32Mbytes of memory. That isn't small, that's high-end desk-top performance of a few years ago.
As for Qt, there is almost no handheld software written in it. Almost all handheld software for Linux is written using FLTK. And many desktop applications could be adapted to handhelds by simplifying their existing user interfaces within their toolkit--much simpler than a rewrite using a different toolkit. Commercial developers are not going to line up to rewrite their software for Qt.
As for consistency, forcing everybody to use the same toolkit is neither necessary nor sufficient to achieve consistency.
Did you even read the message you are responding to? X11 runs fine on the AgendaVR (a 66MHz MIPS) and the iPaq (a 200MHz ARM). It was developed on and for low-end DEC workstations with considerably less power. I won't repeat the other arguments.
CS itself doesn't have to be mind-numbing either: it can be about working with people, about writing, about graphic design, and lots of other things.
Linux PDAs won't take over the consumer market from Palm, but they are good platforms for vertical and custom software (medical, scientific, legal, etc.). But people who write that kind of software already have languages, environments, and toolkits for their domains, and those languages and toolkits are usually not Java, C++, or Qt. X11 would allow applications created in different environments to co-exist, but Qt/Embedded forces everybody to use Qt.
I hope Sharp will put X11 on the device. They can keep their Qt applications by switching to Qt/X11 for their applications. If they don't base the UI on X11, I think they are going to miss their target market.
(In case you want to bring up the "performance" argument for using an "embedded toolkit", a 200MHz ARM is the equivalent of a desktop machine from a few years ago, machines that ran X11 with no problems. X11 was actually developed on and for machines less powerful than today's low-end Palms.)
Now, people who either don't want to have their actions documented or who like to profit even more from images and ideas that really belong to the public can use the excuse of combatting terrorism to exclude cameras from even more places. Well, compared to the other things terrorism has been used as an excuse for (vastly expanded police powers, lots of layoffs and business failures, almost complete abolition of civil rights for immigrants), I suppose this one is still fairly minor.
That's a gross mischaracterization. First, ARM has had a legal victory, but which claim that was actually based on was never decided. Concluding from that that ARM has "successfully defended" any particular aspect, or the entirety, of their architecture is just wrong.
Second, there is no indication that any form of "IP theft" has occurred. Creating a core from scratch that works like the ARM chip is entirely legal in and of itself.
As for you "microwave bacon cooker" example, you can legally make something that doesn't infringe the patent, no more and no less. Since the basic technology for microwave bacon cooking has been known for a while, their patent may not protect anything particularly important, and you may well be able to copy most of their engineering effort.
On balance, I'd say: don't use it unless you really have a very compelling need. View MS Office documents in StarOffice or AbiWord and submit bug reports for any problems you find; that's how those programs get better. As for Quicktime, complain to the web site using it and ask them to use an open format instead (in fact, do that whether or not you actually have a Quicktime viewer).
I don't see much purpose to the ISS. We should concentrate on robotic missions for now: they yield much more information per dollar spent. NASA seemed to think so as well; the ISS seems to have mostly been pushed through for political reasons, not for scientific ones. (Of course, I still prefer the ISS to bombs, but that's another matter.)
But if a system is designed in such a way that people frequently make a certain mistake, and if it is easy to change the system, without limiting its functionality, to keep people from making that mistake, then the system has a design flaw. This applies to the Bourne shell, and that's presumably why its successor at Bell Labs doesn't behave this way anymore.
As for Apple, they should have been using decent package management. If they do need to script, they should have been using a scripting language that gets this right (Perl, Python, etc.). As a last resort, they should at least know their tools.