What Killed Smalltalk?
I’ve been thinking about designing my own programming language for a long time. I’ve actually been keeping a lot of notes, and even throwing together some code when I can find time. My plan is to build something that takes inspiration from LISP, JavaScript and Smalltalk. I think there’s a niche to be filled. There are many new programming languages coming out lately, but most of them are statically typed and compiled ahead of time. The dynamic languages that do come out often don’t perform very well (see CPython, Ruby) or have poorly thought out semantics.
I’ve written a few blog posts pointing and laughing at perceived failures of JavaScript, but the truth is that programming language design is hard. There’s no limit to the complexity of the things you can build with programming code. No matter the design choices you make, no matter the language you design, there are bound to be some inconsistencies and weaknesses somewhere. I think that Smalltalk is a very inspiring programming language, revolutionary in many ways, but it’s also one that has gone extinct. It’s interesting, in my opinion, to ask ourselves why Python thrives but Smalltalk died.
Like LISP, Smalltalk implemented some interesting features which have influenced other languages (such as Java and JavaScript). Some nifty features of Smalltalk are really cool, but still aren’t implemented in any other language. For instance, Smalltalk had the ability to suspend running programs into a saved image, and resume execution later at the saved point. As you can imagine, this is extremely powerful and useful. Forget saving documents or saving games, just save the state of an entire program, no implementation effort required.
I found an interesting talk on YouTube titled “What Killed Smalltalk could Kill Ruby Too”:
Robert Martin makes the case that one of the big weaknesses of Smalltalk is that it was just “too easy to make a mess”. Smalltalk was highly dynamic, and encouraged people to “monkey patch” things and do quick fixes/hacks. He also makes the point that Smalltalk just “didn’t play well with others”. When you think about it, Smalltalk had its own source control, IDE and GUI built into live images, living alongside your program. Smalltalk isn’t just a language, it’s an operating system and a way of life. It’s conflating things that would maybe be best left separate.
It seems to me that in some key areas, the Smalltalk creators placed their own radical ideas above everything else. They chose idealism over pragmatism. Smalltalk was a language created with a grandiose vision. It had some deeply rooted principles which didn’t necessarily work so well in practice, such as the idea that everything had to be an object, that the object metaphor should be applied everywhere, one size fits all. At the end of the day, programmers want to get things done and be productive. If the language design or implementation gets in the way of getting things done, people will leave. Pragmatism is key for a programming language to succeed.
Smalltalk was also designed with the idea that it should be easy to learn and intuitive. This has led its creators to have a heavy focus on graphical user interfaces. I watched an introduction to Self on YouTube (Self is a direct descendent of Smalltalk) and saw the heavy emphasis on interacting with objects through UIs. The user interfaces showcased in this video are, in my opinion, horribly complex and unintuitive. Pretty much all of the interactions done through the UI would have been simpler and easier to understand if they had been done by writing one or two lines of code instead!
When you sit down and think about it for one second, you have to realize that programming doesn’t fundamentally have anything to do with graphical user interfaces. Yes, you can use programming code to create GUIs, but there is no reason that programming should have to involve GUIs and be tied to them. The metaphor of writing code has been extremely successful since the very beginning, and it probably makes more sense to the mathematical mind of a skilled programmer. Not everything has to have a visual metaphor. This is again a case of pushing some idealistic principle too far, in my opinion.
I believe that a lack of pragmatism is something that has killed many languages. Not just Smalltalk, but Scheme too. My first experience with Scheme involved trying and failing to install multiple Scheme distributions because I couldn’t get all the dependencies to work. Then, finally getting a Scheme compiler installed, and struggling to implement simple routines to parse text files, because Scheme doesn’t include the most basic string routines. The Scheme compiler I’d selected bragged that the code it produced was highly optimized, but once I finally managed to write my own string routines, I compiled my program, ran it, and it was dog slow. Parsing a one-megabyte CSV spreadsheet took over a minute. I ended up rewriting the code in Python. Why don’t more people code in Scheme? Because they try to realize their ideas in Scheme, and it just doesn’t quite work out.
Pointers Gone Wild 
Beside all your topic related points I think a big bunch of success of quite a lot of languages is just the lemmingness of people. I’m wondering a lot about some hype stuff and how bad things are done.
On the other side, very few see the real beauty in a language and environment it lives in. It’s not only the language but how you deploy stuff, how you maintain things done with it, how many stuff you need to take care about etc.
“I believe that a lack of pragmatism is something that has killed many languages.” – Yep, and it takes time to “get the idea” and develop a personal style in a pragmatic way. If this is not possible, the language is not suitable.
Regarding the “BYOL” (build your own language) I can fully understand that. Some inspiration and things to take a look, that you might not know are:
1. Rebol: http://www.rebol.net (take a look at R3) It’s not the perfect language but if “get the idea” it’s very pragmatic. A lot of people look to see if A, B or C is available and leave. Bite the bullet and give it an intensive try… I think you like it.
2. D: http://www.dlang.org (compiled) Which I like a lot and it’s incredible productive to use.
I use 1 & 2 in combination and don’t care about the rest only wondering what others are fighting with all the day… and shaking my head.
I often see “principled” and “practical” held up, as in this post, as opposite ends of a spectrum. As if you can’t have “everything is an object” *and* “good tooling” at the same time. As if having a coherent abstraction is somehow *opposed* to getting actual work done. In my opinion this is a *very* dangerous line of reasoning, because the ultimate conclusion is that if you want success you have to design a disgusting mess like PHP.
In practice, “pragmatic” with regard to a programming environment does not have anything to do with compromises with idealism: it simply means “has good support for the fashions of the time”. At the time that Smalltalk was created, there were no fashions at all: computing was in its infancy. However, with the rise of C, C++, UNIX, and Java, the fashions that arose were “source code goes in plain text files”, “version control operates on plain text files”, “networking happens via the socket API”, and so on.
Smalltalk’s failure is very easy to relate directly to its failure to provide good support for these things. It could very well have held onto its principles (EIAO, AYCDISAM) while still providing support for the integration environment (ld.so) and tooling (cvs, gdb) of the time. Later languages that have enjoyed more success (Python, Ruby, Clojure, etc) pretty much did just that. GNU Smalltalk even adapts Smalltalk itself to that type of environment, although GNU’s licensing regime is extra-atrocious for something at the absolute bottom of the stack like a programming language so it has never really seen any use.
The fact that Ruby allows you to make a horrible mess is very definitely a problem. However, Python *technically* allows very nearly the exact same level of hackery, but you will see that it is *culturally* far less pervasive in that community. So Ruby is not really in danger of dying Smalltalk’s death; first, it has far fewer hurdles to overcome (you can definitely put some .rb files into git, for example) and second, the solutions to those problems are largely cultural, not technical. If it’s going to die it’s going to go its own way.
>>Robert Martin makes the case that one of the big weaknesses of Smalltalk is that it was just “too easy to make a mess”.<<
Just because Robert Martin says something, doesn't mean it's true :-)
For sake of argument, let's say that was a weakeness of Smalltalk — that still doesn't answer the question "What Killed Smalltalk?"
As someone focused on technology, I don't like to admit it but whatever the technical weaknesses may have been, the low-volume high-license-price business model and bad business decisions of Smalltalk vendors could not compete with Free-as-in-Beer Future-of-the-Internet Java marketing.
If you design a language that becomes as successful as Smalltalk, you'll have done very well!
July 20th 1992 “C++, Smalltalk vie for object-oriented favor”
>> the low-volume high-license-price business model and bad business decisions of Smalltalk vendors could not compete with Free-as-in-Beer Future-of-the-Internet Java marketing
A very fair point. Surely the price was another contributing factor.
The Smalltalk license price was irrelevant.
The point is that free-as-in-beer allowed anyone with a computer who wanted to become a programmer to learn Java, which was heavily marketed as the-future-the-internet / mobile phones / etc.
Marketing works.
Price matters too. If you had to pay money for a Smalltalk license to have access to “good” Smalltalk tools, that surely discouraged a lot of people. I mean, Squeak is surely VERY different from the Smalltalk banks and finance companies used.
I first played with code when I was a teenager. During my formative years, I only had access to cheap hardware and free tools & documentation. My case is a little extreme, because I was raised by a single mother on welfare, so whatever tools I used *had* to be free, but you get the point. This was around 2000. I didn’t learn Java. It may have been marketed well in educational circles, but I wanted to make videogames, so I used GCC and learned C++ and OpenGL.
I don’t think C++ had the huge marketing push that Java did. It didn’t have a megacorp backing it. It was perceived as hard to learn, clunky and “dangerous” (you can shoot yourself in the foot, etc). The reason so many people learned C++ though, included 16 year old me, is that this is what a lot of real-world software was (and still is) written in. Nobody made first person shooters in Java.
>>Price matters too. I don’t think C++ had the huge marketing push that Java did. It didn’t have a megacorp backing it.<<
AT&T
Microsoft, Intel, Borland, …
MS and Borland had prominent C++ implementations, but there was no unifying force behind C++, no one standard C++ implementation. That’s quite different from say, Java and C#.
I mean, if you’re going to argue that C++ succeeded because of marketing, don’t forget there was, at one point, a significant amount of commercial backing for Smalltalk too.
>>argue that C++ succeeded because of marketing<<
I said that Java succeeded against Smalltalk because of marketing and Java was given away.
C++ competes against C.
I worked for a company that made a version of SmallTalk. I agree with Robert Martin’s points. In the end, SmallTalk was a language that was for the elite, who could afford it, who could afford to learn a whole new paradigm, who could write whole systems from scratch. Elitism is one of Martin’s points. Making a mess was another, which he said was cured with TDD. This talk is now 6 years old and Ruby is fast, and it is still around. But it’s probably not thriving.
The reason our company died and the other SmallTalk companies died was simple: we did not correctly see that the world was changing. SmallTalk was and is a wonderful language. Java was free, and was written to address the problems of networked computing which Sun hoped would be enough to get people to buy their expensive networked computers. Sun died, too because computers were changing by getting cheaper. Java didn’t die.
Java is the one language everyone knows (or should). This will eventually change because Java is needlessly cumbersome and doesn’t solve today’s problems. But it’s what anything that is thriving now is built in because it is good enough, and everyone knows it. JavaScript is the new lingua-Franca that everyone knows (or should), and it’s also not on anyone’s list of most loved languages. But it solves today’s and tomorrow’s problems.
Ruby, SmallTalk, Go, Rust, Clojure, Lisp and all the other beautiful works of art make us dream. Then we write in Java and JS and make a paycheck. Write a new language if it makes you happy. But software is no longer a hobby. It’s a critical part of everything we do, and we’re doing a horrible job of it, not because we have bad languages, but because we have bad code. Make a way of making Java or JS suck less and you will have solved a real problem.
My two cents.
My programming language (Zeta is what it will be named), I’d like to have some success with it, but I think I have reasonable expectations. I’m doing it for fun, first of all. It’s my hobby project, my little piece of art. I’m going to implement features that don’t exist in other languages. If I can learn things, and if my language can influence others, that’s good enough. If I can bring together a small community of hobbyists, that’s good enough. If it doesn’t work out, I’ll change the language, learn from my mistakes, and Zeta 2.0 will be even better ;)
There are so many points on this page that I would like to respond to so I don’t know where to start :) First of all, it’s “Smalltalk” not “SmallTalk” ;)
Isaac is mainly right here, not Robert. One can argue technical merits of Smalltalk, but one should also know that C++ had 60% with Smalltalk 33% of the OOP market at the time. Smalltalk was actually quite successful, but expensive.
Secondly, Squeak is actually a fully proper direct descendant of Smalltalk-80 and definitely VERY close to the commercial offerings, language wise. Of course, VisualWorks and IBM Smalltalk (and others) had more mature tooling, better performance and better integration with UI.
The “making a mess” argument doesn’t hold IMHO, Smalltalk doesn’t encourage messiness that much, at least not compared to say Ruby or Javascript. The image model is also often blamed, but that is IMHO also not a valid observation. The fact that a lot of the vendors were slow/bad in making good integration with SCM tools etc, sure, valid point, but not a killer.
Sam’s comments on image model, just look at GemStone which basically is “the image model taken all the way”. They sure proved it’s damn awesome. And JPMorgan uses Smalltalk/GemStone to make billions in derivatives, so … not bad.
Many more things I could comment on, but my most important thing is to you Maxime:
“But software is no longer a hobby” – I disagree 120% :) It is in fact a very strong hobby for a LOT of people.
So make something cool, have fun doing it. It really doesn’t matter where it goes, it has value nevertheless. And don’t let anyone tell you otherwise. And if you want to get a better feeling for what is good/bad in Smalltalk – ask long time Smalltalkers like me and I will gladly tell you. :)
I think what Isaac is trying to say is that _any_ price is a barrier. By requiring a financial transaction the language loses the ability to spread friction free.
The last compiler I purchased was in 1992, 23 years ago. The only company making any money with dev tools is Jetbrains.
Language adoption is a very rich and interesting field of psychology and sociology. Why is PHP successful? R, Python, WordPress or Ruby? How did Go gain so much mind share when it was already so close to the existing D language? Why haven’t concatenative languages spread outside of their niche?
One thing we have to take into perspective is we have an increasing rate of conversion of domain experts into some sort software development. Code is getting used by more people in more areas along with rising population. If we weigh the size of each domain we could also ask, “Why did web dev kill off everything else?” The number of people that try and learn Python each year greatly surpasses everyone who ever used it in its first ten years of existence. Python, modeled as a communicable disease is easier to spread than Matlab and at the same time can easily mutate to other domains.
Uncle Bob is a great presenter, but I think Killed is the wrong word and simply “making a mess” isn’t an adequate explanation. Lots of things are messy and successful (PHP, Perl) , just as lots of things are clean and not as successful (Ada, Modula-3). By whatever metric on chooses, the success or failure of a technology rarely has to do with the technical merits of that technology.
I think glyph has it right here: “the fashions that arose were ‘source code goes in plain text files’, ‘version control operates on plain text files’, ‘networking happens via the socket API’, and so on. Smalltalk’s failure is very easy to relate directly to its failure to provide good support for these things.” The whole monolithic-image thing is *the* biggest thing that made Smalltalk so not-pragmatic. And glyph is right that “deeply rooted principles” are not the cause of “non-pragmatism”. It should be possible to design a “modern, practical” language that adheres to all (well, most) of the beautiful elegant principles espoused in 1981 here: http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html, including a nice IDE. I keep hoping someone will do it, and I keep being disappointed by all the new languages. I’ll check out REBOL and D. [fwiw, I was a developer of Smalltalk/V and other Smalltalks after that, and have been cranking along with Java for years.]
No one has mentioned the 800 pound gorilla, multi-core/multi-threading. Any language who solves multi-threading and is pragmatic will be the next major language. So far the most interesting stuff I see is the functional area.
I somewhat laugh about writing a new language. My brother-in-law has been doing that for the last 10+ years. So I have had many discussions on languages. The language he is going to write has changed many times. Sometime it depends on what language he was using in his day job which has included OCAML, Clojure and Java. He is real down on dynamic typing, especial in Clojure. At the current startup he is working at, he is rewriting hunks of the Clojure code in Java to make it stable. Your probably best to pick some idea and stick with it.
I’ve currently talked my boss into letting my write a declarative language to describe constraints and data objects that are fed to numerical equation solver. The most interesting part is determining which variables get computed immediately or throw in the equation solver.
Kurt
I think glyph has it right here: “the fashions that arose were ‘source code goes in plain text files’, ‘version control operates on plain text files’, ‘networking happens via the socket API’, and so on. Smalltalk’s failure is very easy to relate directly to its failure to provide good support for these things.” The whole monolithic-image thing is *the* biggest thing that made Smalltalk so not-pragmatic. And glyph is right that “deeply rooted principles” are not the cause of “non-pragmatism”. It should be possible to design a “modern, practical” language that adheres to all (well, most) of the beautiful elegant principles espoused in 1981 here: http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html, including a nice IDE. I keep hoping someone will do it, and I keep being disappointed by all the new languages. I’ll check out REBOL and D. [fwiw, I was a developer on Smalltalk/V and other Smalltalks after that, and have been cranking along with Java for years.]
Do you know julialang.org? Julia is a dynamically typed language, has Lisp (Scheme) like macros and Multiple dispatch.
I think you forget the context that Smalltalk was in during the early to mid 1970ies. There was effectively no other world to interact with, they invented, had to invent, (proto-) personal computing. However, the creators of Smalltalk were very aware of this, and saw Smalltalk primarily as the best way to replace itself. Alas, that never happened, and the vendors took Smalltalk as a thing to be learned and sold “as is”.
Mind you, it was and is still pretty amazing “as is”, but just as the vendors tried to cash in on the amazingness, the market for programming languages and high-end development environments largely evaporated.
However, Smalltalk never died, it just didn’t become as widespread as it could have. Squeak and Pharo are open-source versions with vibrant communities. Cincom Smalltalk is still around as is Gemstone/S. F-Script is a Smalltalk variant for Mac OS X. Amber is a Smalltalk for the the browser. Gravel is a Smalltalk running on the JVM.
My own Objective-Smalltalk generalizes Smalltalk’s concepts to software-architectural ones. So messages generalize to connectors. Objects, classes and methods generalize to components. Identifiers generalize to URIs and the local/instance/pool/class variables generalize to composable scheme resolvers.
(@Tom Harrison: having a hard time believing someone who worked at one of the Smalltalk vendors doesn’t know how to capitalize the name properly.)
“For instance, Smalltalk had the ability to suspend running programs into a saved image, and resume execution later at the saved point.”
As far as I’ve been told, that feature was a great idea, but never worked reliable enough for production use. Also, this is a headache when the application evolves. How do you transfer the user data out of an old image into the image of your new version?
So you need to define a stable data exchange structure anyway. And if you do that, why not using exactly that one for saving to files, too?
So I guess that this image concept is overrated, except for rare usecases. But for those cases (e.g. hot-patching of running operating system kernels), it isn’t good enough by far.
“I think that Smalltalk is a very inspiring programming language, revolutionary in many ways, but it’s also one that has gone extinct.”
Hardly extinct. The language is still in use around the world — just ask the people in ESUG. Moreover, Pharo is actively evolving (with many interesting things on their roadmap).
I personally know of two companies doing substantial business in Smalltalk consulting (Cherniak Software and Simberon).
I wonder: what is your dictionary definition of “extinct”?
“At the end of the day, programmers want to get things done and be productive.”
Indeed, one can be extremely productive with Smalltalk. Research confirms this: https://smalltalkrenaissance.wordpress.com/2015/02/16/smalltalks-proven-productivity/
“When you sit down and think about it for one second, you have to realize that programming doesn’t fundamentally have anything to do with graphical user interfaces.”
That’s true as far as it goes. However, the special thing about Smalltalk is that its unique combination of impossibly clean syntax, live coding and debugging, and consistent object model creates a synergy unmatched in the IT world. It is this synergy that confers enormous productivity (https://medium.com/smalltalk-talk/t-h-o-r-25b62437175c). Smalltalk’s graphical IDE and image get most of the credit.
Unlike Scheme, Smalltalk has been well-used in industry. It is a very practical language. It may not be suitable for all problem domains, but the majority are well-served.
I worked for Digitalk and ParcPlace between ’94 and ’96, and the simple fact is that ParcPlace-Digitalk was taken down by a complete market disruption called the internet and Java…
Sun at the time put in so much marketing muscle and so much hype surrounding Java into the market place that the few Smalltalk vendors just couldn’t survive.
I remember customers calling us and literally saying “Hey, we love your stuff, but Sun came out with this Java stuff that looks cool… we’ll hold off on renewing that site license we have…”. Revenues collapsed, stock price collapse followed, the company went into crisis management mode, downsizing, the original creators and thinkers left for other big name internet success stories of the time (Sun, Netscape, AOL, …).
Last but not least, the advent of the open source community was taking shape… LINUX was becoming a viable alternative to traditional commercial UNIX implementations… the entire business model changed… Back in the 90’s you had small to medium sized independent software development tools vendors (Symantec, Borland, etc.) that were able to sell tools / compilers / utilities for profit, but with the exception of the big boys that have operating system or DB tie ins like IBM, Microsoft, Oracle they are all gone, subsumed by free tools, free languages, open source all the way.
So, yes, there are language and OO and technical discussions that are valid, but Smalltalk died because of a radical market disruption. Because it was a niche player at the time, it died, it could not sustain itself on legacy users like C/C++ or COBOL.
It sure as hell was a good language and system for its time, and it heavily influenced many languages that followed.