Why Don't More People Use Smalltalk?

RevAaron asks: "With Java, and now C#, we're seeing the same (then revolutionary) concepts and features that Smalltalk had over twenty years ago. With open source versions like Squeak and GNU Smalltalk, not to mention numerous other versions, most of which have an free (as in beer) version available, why hasn't the open source world adopted it to a larger extent? It boggles the mind that the open source community hasn't picked it up, even with almost all of the source of the entire Smalltalk system available to developers, even with the commercial implementations. Is it simply a case of 'once a C coder, always a C coder,' with languages like C++ and Java being used by virtue of their Algol-derived syntax?" The choice of language of most developers is a queer thing indeed. I'm still surprised that COBOL has lasted for as long as it has. So if anyone has any insight as to why Smalltalk use isn't more widespread, please share.

Comments

Lack of Speed and Efficiency

[Valdrax]

Now it's one thing for people to nitpick about the differences between C and C++, but has anyone ever seen any implementation of Smalltalk that could be described as fast? Smalltalk is a wonderful language. The design is beautiful, powerful, and simple. However, the actual implementation of language interpreters is usually heinously slow due to a number of design issues with the language. You can't even do a simple '2 + 2' without involving objects. The beautiful, but odd block statement syntax makes interpretation very awkward and tricky as well.

My college uses an open-source Smalltalk variant known as Squeak for it's OO classes. (It was made for Disney of all people -- hence the name.) One of my favorite stories of Squeak inefficiency came from a conversation I overheard about one student having a problem with Squeak running out of memory trying to create a PostScript file. The problem was that each time you appended to the object, it made a copy of the original object and then appended to the copy. These huge copies were being passed around in memory over and over again until the VM simply ran out of room. This ridiculous waste of memory and CPU cycles comes from fundamental design problems with the language. It's wonderful but way too abstract to get real-world performance.

Proponent (long)

[Lord of the Fries]

I have written thousands of lines of Fortran, embedded C, poured over tons of Java and C++, and done Smalltalk for 9+ years. Anywhere I *can* get Smalltalk to fit, I will use it. Why? Because it is different. And it's probably these differences that slow its adoption by the hacker/hobbyiest community. Namely: Everything is an object: It's all about message sending in Smalltalk. This is especially powerful in large/complex/evolutionary systems. It's also very elegant; a real sense of uniformity. Syntax: Took me a couple of weeks to get used to it. Now I laugh at most of the others. Five reseverved keywords. The majority of the language elements in one method. Approximates natural language very well. The Image Programing Model and IDE: Once you grok it, very powerful. But again, a hurdle that if approached with a shoehorn just punishes you. The object based browsers. People still insist on browsers that just show flat files and "jump" you to the appropriate code point when you navigate to a method. It's amusing to watch many struggle with (and ultimately reject) VAJ, which attempts to bring code navigation within reach of the 20 year old Smalltalk browsers. It's too easy: I get a certain rush out of eeking a few percent out of an embedded C program, by playing a number of "tricks". There's a real sense of "I climbed the hill!", even though it is small. It has been fascinating to watch even some members of the Smalltalk community spend the last 5 years in Java work there tails off to come up with shoddy re-implementations of something they did easily in Smalltalk. But in Java (or C++, or whatever), it's more of a challenge. So either be prepared to discover the good ol' problems have been solved, or start solving some new ones. Problems that have historically hindered, but no longer do: Vendor Viability: IBM does Smalltalk. Cincom (one of the most succesful privately owned companies in the software industry) does it. The Squeak project has enjoyed quite a swell of momentum; anyone who went to ANY of the last three OOPSLAs would know this. Speed: For raw number crunching, Smalltalkers cede to C. Most of the Smalltalk's have robust methods of integrating C code for tight/primitives to speed optimize that critical 5% of your code. And when it comes to message dispatch, Smalltalk has won a number of benchmark tests. GC implementations in the 8 major implementations leave other lang GCs behind. Price: Squeak is open source to the bare bones. And it's extremely portable. It's been ported to a plethora of chips. The high priced vendors have come out with better pricing models (though there is still room for improvement). There are different entry price models. OS integration: Again much improved. MT allows one to write ST DLLs (very fast too). QKS has a .NET implementation. There are Unix shell implementations. Dolphin has great Win32 integration. ST/X has a plethora of built in Linux tools. I have watched a number of people take a run at Smalltalk. Seems that most are either wildly succesful; have the "aha" experience and fall in love. Others just never get what it is the rest of us get excited about. I have tried to track why some do and don't. The only distinguishing attribute I have been able to find is "ya gotta wanna." Those who have really had the desire to stick with and find out why a 30 year old language still has such strong advocates, is willing to eventually fall out of their box, and discover that in some cases, different has advantages. But many people can just never get beyond the differences. It is interesting to note that in a spectrum drawn between Smalltalk and Assembly, languages have spent the last 30 years slowly evolving towards the Smalltalk end. In the end it may not be Smalltalk that we all use. But new languages will continue to be more and more like Smalltalk in spirit. Maybe Smalltalk will continue to innovate and offer these back to the evolution of mainstrema languages; maybe sufficient convergence will finally be achieved, and we'll all jump on whatever bandwagon has really caught up.

Yes but...

[X]

Certainly Smalltalk has it's merits, but it also has it's shortcomings:

• It lacks Java's interoperability guaruntees, limiting the ability of end users to choose among multiple 3rd party vendors
• It does not define a stable runtime (developers can and generally do modify almost all the fundamentals of the system) making it hard for 3rd party vendors to sell add ons.
• A direct corollary of the previous point is that Smalltalk developers constantly reinvent the wheel. When I work with a Smalltalk team, a good deal of design effort is spent on architectural domains like exceptions, transactions, persistence, etc. With Java, all that is already there. Sure, a group of excellent programmers designing an architecture for a specific purpose will likely produce something better than a general purpose API, but it is hard from a business standpoint to justify the effort.
• A strong NIH mentality within the Smalltalk community. A good example was your GC argument. In fact, Smalltalk GC's lagged LISP GC's in much the same way that Java GC's have lagged Smalltalk.
• Slow adoption of modern OS capabilities, in particular threading comes to mind. You might get one vendor adopting a particular capability, but you didn't have something uniform.
• Too much proprietary effort. Companies have tried too hard to wring profits out of Smalltalk, and as a consequence squandered it's commercial viability.

Probably the biggest problem of Smalltalk though is that while it does a great job of leveraging an excellent programmer's work for a project, it also does an great job at leveraging the damage a beginning programmer can do. When Smalltalk DID get in the limelight, it didn't have enough excellent programmers around (and it takes a while to create more excellent programmers). While some companies are enlightened enough to focus on getting the top programmers, most are not (nor good they). This is where Java, Visual Basic and Delphi are much stronger than Smalltalk.