I've seen a few posts on this topic implying that "well sure, maybe you can write an app in Lisp in less time and with similar performance, but it's not going to be as maintainable as a Java/etc app."
There is zero evidence to back up the notion that a Lisp (e.g. CLOS) app would be less maintainable. Of course, there's not a lot of evidence either way, but there's at least a little evidence that it might be more maintainable:
This table shows that CLOS requires fewer lines of code (LOC) per function point than Java, in other words a typical CLOS app will require fewer LOC than an equivalent Java app. This data roughly jibes with the LOC results from the NASA/JPL study. This makes CLOS a "higher-level" language than Java.
Anyway, apps written in higher-level languages are easier to maintain than apps written in lower-level languages, simply because there is less code to worry about. Less code to do the same task also usually means that there is less code duplication, which is a common source of bugs. Thus, we would expect that a CLOS app, on average, would probably be easier to maintain than a Java app. (Yes, there are other factors in what makes a language more or less maintainable, but high-levelness is one of the few that is actually measurable.)
Granted, the SPR languages table is rather coarse-grained... apparently a lot of the levels for languages were extrapolated from other languages based on language features. (e.g. I think Java probably deserves a slightly higher language-level rating than C++, but then again Java lacks some things like genericity which might partly offset its LOC gains from automatic memory management/etc versus C++. Same goes for Scheme deserving a higher level.) But still, the table seems to be roughly accurate from my experience with programming various languages, and it's the best data we've got. It would be great if better and more detailed studies could be done comparing languages for developing (and maintaining!) larger, real-world apps, but this type of research is difficult and expensive, so it never seems to get done.:-(
Regarding complaints about the NASA study again... same goes for tiny apps versus huge apps. The jury is still out on whether statically-typed (Java/C++/Fortran) or dynamically-typed (Lisp/Smalltalk/Python/Ruby) languages scale better to huge apps. My personal feeling is that dynamically-typed languages scale better, but I don't think there's any real data proving either case. (Something like CLOS in particular with its powerful meta-programming capabilities I think would start to seriously crush Java in terms of maintainability for enormous apps.)
(By the way, I'm mostly a big Smalltalk fan, but I have a lot of respect for Lisp and its variants. I do work with Java too, but I don't find it particularly inspiring.;-) See http://squeak.org for a cool, free, open-source (including the VM!) Smalltalk that runs on most any platform.)
As for a prediction of where Java will be in 30 years... my guess is it'll probably be around quite awhile, having a life-cycle similar to COBOL. Java and COBOL are similar in a lot of ways... neither language is revolutionary in terms of fundamental language features (as opposed to Lisp or Smalltalk), but both had good support for development of business-related apps, and gained a lot of momentum as a "standard"...
Sounds like a pretty good summary. For the most part, it seems that you're better off just going with C++ if you really need the speed, or going with Smalltalk if you need a *real* high-level language for handling complexity well. There's not much of a middle ground where Java is a better option than one of these.
(As the old Bertrand Meyer adage goes... Java: all the elegance of C++ with the speed of Smalltalk.:-) )
On my favorite web job site: The living:- C++ 10251 matches. JAVA 9454 matches. PERL 2451 matches. And the dead:- COBOL 1254 matches. RPG 306 matches. ADA 224 matches. PL/1 132 matches. SmallTalk 53 matches. VAX BASIC 22 matches.
Hmm, by your logic there are only three living languages, then? (C++, Java and Perl?)
I guess Python and Ruby must be even more dead than Smalltalk, since they have fewer hits on job sites.
Market Share can be *a* factor in determining whether or not to use a programming language, but it should never be *the only* factor. If market share is your only factor, you should be using Microsoft stuff and not hanging out on slashdot anyway.
(Ok, I'll grant you that the Smalltalk Solutions report had a stream-of-conciousness feel to it, but it's not easy to write the large volume of material that John did on each day of the conference. He covered most of the important stuff going on.)
Like so many things that recently have made a splash (extreme programming, refactoring, patterns, etc.), this is really just giving a name to programming practices and ideas that have been around for two decades. Smalltalk was one of the languages where such ideas originated (Lisp was another major one), they just didn't originate recently.
Right... it's a good thing that a name was finally given to these practices, though.
Quite to the contrary. While Java isn't as convenient to program in as Smalltalk, the additional type information that Java source code contains lets you do more kinds of refactoring safely. In fact, one of the reasons refactoring has not been such a big deal in the C++/Java world is because static type checking in those languages already helps you with a lot of refactorings....
True, it does cut both ways. The main thing in Smalltalk's favor is the simplicity of the syntax (e.g. there are only 5 reserved words), which makes things a lot easier for the writer of the refactoring tool. And also the fact that you don't have primitive types vs. objects to worry about. But static typing helps Java refactoring. (Declarations like public/protected/private and abstract probably help too.)
Still, my impression is that the Refactoring Browser for Smalltalk is still the most powerful one out there. I'll have to take a look at jFactor to see how it compares, though.
Yes, Smalltalk has been around for awhile, but it is still the source of new ideas and trends in certain areas. For example:
Extreme Programming. The extreme programming (XP) methodology grew out of a Smalltalk project 3-4 years ago. The founder of extreme programming, Kent Beck, advocates Smalltalk as the most productive language for XP, as does Ron Jeffries, the author of the Extreme Programming Installed book.
Refactoring. The term "refactoring" has become popular in the last few years, due in large part to the work done on the Refactoring Browser for Smalltalk by John Brant and Don Roberts. (Martin Fowler's book on Refactoring includes a section on the Refactoring Browser.) The Refactoring Browser lets you perform automated behavior-preserving code refactorings, such as abstracting references to an instance variable, pushing a method up into its superclass, etc. (There have also been some refactoring tools written for Java, but the nature of the Java language will make it difficult to create a tool as powerful as the Refactoring Browser for Smalltalk.)
IDE's (Integrated Development Environments). Smalltalk has generally been considered a leader in this area, with its integrated code browsers, the ability to reliably look up all senders or implementors of a method, etc. (There is the occasional effort in other languages to catch up in this area, such as VisualAge Java with its integrated browsers, but VA/Java was also written in Smalltalk.) Also, to shamelessy toot my own horn for a minute, I've created an object-oriented "stacking" code browser for Squeak/Smalltalk called Whisker. I used Smalltalk to create this because the IDE supports this sort of experimentation well.
So, to claim that Smalltalk is somehow dead or obsolete is obviously false. True, it doesn't have the marketing hype (and market penetration) that Java does, but then, what else does?:-)
(Also, I still consider the language features of Smalltalk to be more technically "advanced" than those of Java. My personal hunch is that if you conducted a random poll of developers with *significant* experience with both languages (say, a minimum of 1 year full-time experience with each), probably 90-98% would agree with this. Of course, the same is probably true of Scheme vs. Java, or CLOS vs. Java, etc.)
Anyway, Smalltalk is obviously not the answer to all programming problems. (I wouldn't use it to write a device driver, for example.) But it is still one of the best (if not *the* best) options for many larger programming problems.
Slashdot Mirror
There is zero evidence to back up the notion that a Lisp (e.g. CLOS) app would be less maintainable. Of course, there's not a lot of evidence either way, but there's at least a little evidence that it might be more maintainable:
http://www.spr.com/library/0langtbl.htm
This table shows that CLOS requires fewer lines of code (LOC) per function point than Java, in other words a typical CLOS app will require fewer LOC than an equivalent Java app. This data roughly jibes with the LOC results from the NASA/JPL study. This makes CLOS a "higher-level" language than Java.
Anyway, apps written in higher-level languages are easier to maintain than apps written in lower-level languages, simply because there is less code to worry about. Less code to do the same task also usually means that there is less code duplication, which is a common source of bugs. Thus, we would expect that a CLOS app, on average, would probably be easier to maintain than a Java app. (Yes, there are other factors in what makes a language more or less maintainable, but high-levelness is one of the few that is actually measurable.)
Granted, the SPR languages table is rather coarse-grained... apparently a lot of the levels for languages were extrapolated from other languages based on language features. (e.g. I think Java probably deserves a slightly higher language-level rating than C++, but then again Java lacks some things like genericity which might partly offset its LOC gains from automatic memory management/etc versus C++. Same goes for Scheme deserving a higher level.) But still, the table seems to be roughly accurate from my experience with programming various languages, and it's the best data we've got. It would be great if better and more detailed studies could be done comparing languages for developing (and maintaining!) larger, real-world apps, but this type of research is difficult and expensive, so it never seems to get done. :-(
Regarding complaints about the NASA study again... same goes for tiny apps versus huge apps. The jury is still out on whether statically-typed (Java/C++/Fortran) or dynamically-typed (Lisp/Smalltalk/Python/Ruby) languages scale better to huge apps. My personal feeling is that dynamically-typed languages scale better, but I don't think there's any real data proving either case. (Something like CLOS in particular with its powerful meta-programming capabilities I think would start to seriously crush Java in terms of maintainability for enormous apps.)
(By the way, I'm mostly a big Smalltalk fan, but I have a lot of respect for Lisp and its variants. I do work with Java too, but I don't find it particularly inspiring. ;-) See http://squeak.org for a cool, free, open-source (including the VM!) Smalltalk that runs on most any platform.)
As for a prediction of where Java will be in 30 years... my guess is it'll probably be around quite awhile, having a life-cycle similar to COBOL. Java and COBOL are similar in a lot of ways... neither language is revolutionary in terms of fundamental language features (as opposed to Lisp or Smalltalk), but both had good support for development of business-related apps, and gained a lot of momentum as a "standard"...
Sounds like a pretty good summary. For the most part, it seems that you're better off just going with C++ if you really need the speed, or going with Smalltalk if you need a *real* high-level language for handling complexity well. There's not much of a middle ground where Java is a better option than one of these. (As the old Bertrand Meyer adage goes... Java: all the elegance of C++ with the speed of Smalltalk. :-) )
On my favorite web job site: The living:- C++ 10251 matches. JAVA 9454 matches. PERL 2451 matches. And the dead:- COBOL 1254 matches. RPG 306 matches. ADA 224 matches. PL/1 132 matches. SmallTalk 53 matches. VAX BASIC 22 matches.
Hmm, by your logic there are only three living languages, then? (C++, Java and Perl?)
I guess Python and Ruby must be even more dead than Smalltalk, since they have fewer hits on job sites.
Market Share can be *a* factor in determining whether or not to use a programming language, but it should never be *the only* factor. If market share is your only factor, you should be using Microsoft stuff and not hanging out on slashdot anyway.
(Ok, I'll grant you that the Smalltalk Solutions report had a stream-of-conciousness feel to it, but it's not easy to write the large volume of material that John did on each day of the conference. He covered most of the important stuff going on.)
Right... it's a good thing that a name was finally given to these practices, though.
Quite to the contrary. While Java isn't as convenient to program in as Smalltalk, the additional type information that Java source code contains lets you do more kinds of refactoring safely. In fact, one of the reasons refactoring has not been such a big deal in the C++/Java world is because static type checking in those languages already helps you with a lot of refactorings. ...
True, it does cut both ways. The main thing in Smalltalk's favor is the simplicity of the syntax (e.g. there are only 5 reserved words), which makes things a lot easier for the writer of the refactoring tool. And also the fact that you don't have primitive types vs. objects to worry about. But static typing helps Java refactoring. (Declarations like public/protected/private and abstract probably help too.) Still, my impression is that the Refactoring Browser for Smalltalk is still the most powerful one out there. I'll have to take a look at jFactor to see how it compares, though.
Extreme Programming. The extreme programming (XP) methodology grew out of a Smalltalk project 3-4 years ago. The founder of extreme programming, Kent Beck, advocates Smalltalk as the most productive language for XP, as does Ron Jeffries, the author of the Extreme Programming Installed book.
Refactoring. The term "refactoring" has become popular in the last few years, due in large part to the work done on the Refactoring Browser for Smalltalk by John Brant and Don Roberts. (Martin Fowler's book on Refactoring includes a section on the Refactoring Browser.) The Refactoring Browser lets you perform automated behavior-preserving code refactorings, such as abstracting references to an instance variable, pushing a method up into its superclass, etc. (There have also been some refactoring tools written for Java, but the nature of the Java language will make it difficult to create a tool as powerful as the Refactoring Browser for Smalltalk.)
IDE's (Integrated Development Environments). Smalltalk has generally been considered a leader in this area, with its integrated code browsers, the ability to reliably look up all senders or implementors of a method, etc. (There is the occasional effort in other languages to catch up in this area, such as VisualAge Java with its integrated browsers, but VA/Java was also written in Smalltalk.) Also, to shamelessy toot my own horn for a minute, I've created an object-oriented "stacking" code browser for Squeak/Smalltalk called Whisker. I used Smalltalk to create this because the IDE supports this sort of experimentation well.
So, to claim that Smalltalk is somehow dead or obsolete is obviously false. True, it doesn't have the marketing hype (and market penetration) that Java does, but then, what else does? :-)
(Also, I still consider the language features of Smalltalk to be more technically "advanced" than those of Java. My personal hunch is that if you conducted a random poll of developers with *significant* experience with both languages (say, a minimum of 1 year full-time experience with each), probably 90-98% would agree with this. Of course, the same is probably true of Scheme vs. Java, or CLOS vs. Java, etc.)
Anyway, Smalltalk is obviously not the answer to all programming problems. (I wouldn't use it to write a device driver, for example.) But it is still one of the best (if not *the* best) options for many larger programming problems.