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.