Well, the experience reports section of the Smalltalk Solutions wiki would be a good place to look. The EZBoard slides aren't up there yet (the second largest online community site, serving 4.5M hits/month out of a pure Smalltalk web server) but the OOCL/Gemstone in the Large presentation (sorry, it's encoded in Microsoft-specific technologies to help keep slashdotters out) talks about the technical details of using Smalltalk and an OODB to run one of the world's largest shipping operations. Elastolab is on a completely different scale, but more fun to play with, and of course the web site hosting the proceedings is running purely in Smalltalk. I've just singled out a few. There's also a Smalltalk article in this month's Communications of the ACM, for those who read offline.
Is that enough of a start?
The first is that the syntax and the environment are a shock for people
raised on file-based, statically typed, "edit it in vi" type of languages.
The second and more important are the business reasons. Smalltalk was doing
quite well commercially in the early 90's, but mostly in the high-end corporate
developer space, with costs of thousands of dollars per developer seat. IBM
had a big push behind it. This frightened the two other big commercial vendors,
who attempted to merge, failed disastrously, and left IBM almost alone in
the market, a position it didn't want to be in. With the high-price policies
there was no low-end or open source base to sustain it. Then Java came along
and picked up a lot of the pieces.
Nevertheless, Smalltalk has refused to go away. Significant open source efforts
have started with things like Squeak and
Camp Smalltalk, and even in the commercial
world VisualWorks has a free download
and Dolphin Smalltalk is an inexpensive
very nice, clean windows environment. For a language that doesn't get used much,
it runs fabs, auto assembly lines, massive payroll systems, and untold numbers
of financial systems including a very respectable fraction of the stock trades
in the United States.
Disclaimer: I recently quit a Java startup (WebGain)
to go work for Cincom on Smalltalk development.
Apologies for the empty post. Hopefully someone will moderate it into oblivion.
Reading this article it really struck me how much he's ignoring. He waxes eloquent about parametric polymorphism, but ignores the languages that do the best job on it (primarily functional). He also spends a lot of time asking for features that (at least mostly) exist in well-known, and well-used languages, that even have open source implementations. My particular example is Squeak (http://www.squeak.org), an open source Smalltalk implementation. There are others, and lots of them have been mentioned
Let's see about his wishlist
an open world so that source and binaries don't need to be changed to use new types. Check. The reference source of generic libraries for things like collections. Sorted list was written once 20 years ago and re-used for all types ever since.
function references bound to objects. Check. Blocks, aka closures. Incredibly powerful, and around for years in languages like LISP and Smalltalk.
higher order functions. Check. Basically the same thing.
simple, natural syntax. Check. His specific example was the APL-like ability to use + on collections. That's something they recently added to Squeak, without having to change anything fundamental in the system
polymorphic types with bounds, constraints, and proper variance relationships fo parameters. He doesn't talk about this in the rest of the article, and I don't really know what it means, so I can't comment.
introspection. The development environment is written in itself. You can introspect anything any which way you want.
built-in security, preferably enforced by the compiler. That's missing, partly because it's pretty hard to combine compile-time security with rich introspection and simple syntax. Security is supposed to get in the way
binary portability. Check. Runs on practically anything, including handhelds.
It even copied that garbage collection idea from Java.
Perhaps the languages of the future just require people to notice what's already there.
Certainly light-weight threads as first order constructs are a very valuable thing. That's the sort of thing you've seen in Smalltalk for a long time. For that matter, it seems like a lot of the lesson of the last few decades is that for almost anything it's useful to have it as a first-order concept. Reflection rules. Hey, Java even has reflection. Sort of.
It's interesting that source control is hardly mentioned, but I think that's because it's a given. Certainly it would be very difficult to practice continuous integration if you didn't have a very solid handle on what you're integrating against. That's certainly the case on the XP projects that I know of, that strong source code control is basic. Clearly, high turnover is a problem for any project, but surely it's better to have most of the people on the team at least have some understanding of the whole system rather than have it confined to few individuals. By doing things in pairs you minimize the risk that one of the people who understood why something was done will be gone in 3 months. By having rigorous and exhaustive tests you provide something that explains in code (the only way that counts) what something is supposed to do, and you ensure that changes by people with incomplete knowledge don't break things.
Slashdot Mirror
Well, the experience reports section of the Smalltalk Solutions wiki would be a good place to look.
The EZBoard slides aren't up there yet (the second largest online community site, serving 4.5M hits/month out of a pure Smalltalk web server) but the OOCL/Gemstone in the Large presentation (sorry, it's encoded in Microsoft-specific technologies to help keep slashdotters out) talks about the technical details of using Smalltalk and an OODB to run one of the world's largest shipping operations. Elastolab is on a completely different scale, but more fun to play with, and of course the web site hosting the proceedings is running purely in Smalltalk. I've just singled out a few. There's also a Smalltalk article in this month's Communications of the ACM, for those who read offline.
Is that enough of a start?
To oversimplify, there are two big reasons
Nevertheless, Smalltalk has refused to go away. Significant open source efforts have started with things like Squeak and Camp Smalltalk, and even in the commercial world VisualWorks has a free download and Dolphin Smalltalk is an inexpensive very nice, clean windows environment. For a language that doesn't get used much, it runs fabs, auto assembly lines, massive payroll systems, and untold numbers of financial systems including a very respectable fraction of the stock trades in the United States.
Disclaimer: I recently quit a Java startup (WebGain) to go work for Cincom on Smalltalk development.
Apologies for the empty post. Hopefully someone will moderate it into oblivion.
Reading this article it really struck me how much he's ignoring. He waxes eloquent about parametric polymorphism, but ignores the languages that do the best job on it (primarily functional). He also spends a lot of time asking for features that (at least mostly) exist in well-known, and well-used languages, that even have open source implementations. My particular example is Squeak (http://www.squeak.org), an open source Smalltalk implementation. There are others, and lots of them have been mentioned
Let's see about his wishlist
an open world so that source and binaries don't need to be changed to use new types. Check. The reference source of generic libraries for things like collections. Sorted list was written once 20 years ago and re-used for all types ever since.
function references bound to objects. Check. Blocks, aka closures. Incredibly powerful, and around for years in languages like LISP and Smalltalk.
higher order functions. Check. Basically the same thing.
simple, natural syntax. Check. His specific example was the APL-like ability to use + on collections. That's something they recently added to Squeak, without having to change anything fundamental in the system
polymorphic types with bounds, constraints, and proper variance relationships fo parameters. He doesn't talk about this in the rest of the article, and I don't really know what it means, so I can't comment.
introspection. The development environment is written in itself. You can introspect anything any which way you want.
built-in security, preferably enforced by the compiler. That's missing, partly because it's pretty hard to combine compile-time security with rich introspection and simple syntax. Security is supposed to get in the way
binary portability. Check. Runs on practically anything, including handhelds.
It even copied that garbage collection idea from Java.
Perhaps the languages of the future just require people to notice what's already there.
Certainly light-weight threads as first order constructs are a very valuable thing. That's the sort of thing you've seen in Smalltalk for a long time. For that matter, it seems like a lot of the lesson of the last few decades is that for almost anything it's useful to have it as a first-order concept. Reflection rules. Hey, Java even has reflection. Sort of.
It's interesting that source control is hardly mentioned, but I think that's because it's a given. Certainly it would be very difficult to practice continuous integration if you didn't have a very solid handle on what you're integrating against. That's certainly the case on the XP projects that I know of, that strong source code control is basic. Clearly, high turnover is a problem for any project, but surely it's better to have most of the people on the team at least have some understanding of the whole system rather than have it confined to few individuals. By doing things in pairs you minimize the risk that one of the people who understood why something was done will be gone in 3 months. By having rigorous and exhaustive tests you provide something that explains in code (the only way that counts) what something is supposed to do, and you ensure that changes by people with incomplete knowledge don't break things.
There are no maintenance people, everything is maintenance after the first iteration.