Why Smalltalk Is Not Popular
January 9, 2011
My previous post was about the trend towards mainstream use of Virtual Machines (VM’s) in application programming.
An issue that has intrigued me over the years is why the Smalltalk language has not become more widely used.
I have been using Smalltalk since 1987 (Digitalk Smalltalk/V) and have been invloved in several large projects with VisualWorks and VisualAge.
So, I know that Smalltalk can be a very highly productive environment for many requirements.
Smalltalk was the original language that inspired much of what we use today including object-oriented programming, windowed interfaces, the IDE, mouse-based commands, etc. In fact, in was Steve Jobs seeing Smalltalk at PARC in 1979 that inspired the Macintosh which then led to Microsoft developing Windows – and the rest is history.
Java came out in 1995, and IBM switched their focus from Smalltalk to Java. Also, ParcPlace had a very bad policy of charging high fees for licensing their runtime. And there were other bad decisions such as the ParcPlace-Digitalk merger. These events are all well-known history…
But I think that the real reason that Smalltalk is not widely used is related to the Smalltalk VM.
In my earlier post, I discussed how most application programs today are built with languages based on VM’s.
And the most widely used client-facing VM’s are:
— .NET CLR
— Java JRE
— Flash ActionScript
— Apple’s Objective-C (garbage collected memory)
Which means that libraries and API’s are built using these same VM’s.
Many languages have been successfully implemented on the CLR and the JRE (IronPython, JPython, IronRuby, Clojure, Groovy, etc) but Smalltalk has always been the exception.
I think that this mainly is due to the fact that Smalltalk uses the runtime stack in a very particular manner (to support “non-local” returns, etc) that is very difficult to implement in the most popular VM’s.
And so, Smalltalk has always depended upon its own custom VM.
Smalltalk can call libraries written in languages like “C” or C++ that do not use “managed” memory.
But for a Smalltalk which on runs in its own VM, it is almost impossible to call a library or an API written in a language like C# or Java that is written in a language written for a different VM.
And so, traditional Smalltalk implementations are increasingly excluded from using native libraries and API’s which are now being written in C#, Java, or other “managed memory” language.
In Silver Smalltalk, I have implemented the Smalltalk interpreter (STVM) itself in native “memory-managed” languages such as C# and Java – so this problem doesn’t occur.
This allows Smalltalk to become fully implemented into the runtime environment and to use all available libraries and API’s. In other words, it allows Smalltalk to run in today’s mainstream environments.