Smalltalk Isn’t Dead: Here’s Why You Should Use It
I recently read a couple of articles reviewing why Smalltalk “died”:
This got me thinking. Why can’t Smalltalk be revived? For the most part, Smalltalk’s weaknesses have been addressed today.
While the Smalltalk community is still somewhat fragmented, there are really only three prominent Smalltalk flavours for enterprise use: open source Pharo, commercial VAST, and commercial VisualWorks. Commercial Smalltalks are important because many enterprise users insist on having solid, reliable, commercial support.
Pharo is becoming increasingly important in the enterprise space, especially with support from the Pharo Consortium.
I’ve run Pharo on a Raspberry Pi and it runs quite well! Pharo plays well with GitHub, thanks to the Iceberg facility. Pharo is web-ready with Seaside and Teapot frameworks, as well as PharoJS for front-end development.
So, why should you use Smalltalk?
Smalltalk has the following winning qualities:
- Simplicity and elegance — Smalltalk presents a very low cognitive load for developers.
- Object-oriented purity — Smalltalk is the ideal way to do object-oriented software development. It supports enormous scalability.
- Imaged-based development — Smalltalk is a better Docker than Docker! It combines an application with an IDE and portable OS platform, complete with everything the application needs in order to execute. (Imagine a VirtualBox or VMware Linux image containing Eclipse and your Java application. It’s like that.)
- All of the above lead to incredible programmer productivity increase, typically 2–3X, in some instances up to 5X! What is it worth to you to cut your development time in half (or better)?
Note 1 — A Smalltalk image is comparable to a VirtualBox or VMware Linux virtual machine running a Java application along with the Eclipse IDE used to create the application. The Linux VM is portable and can be easily deployed anywhere. Smalltalk refined this concept decades earlier!
Note 2 — Smalltalk’s productivity is illustrated in Capers Jones’ study on function point metrics for a variety of programming languages.
Table 16: Side-by-Side Comparison of function points and lines of code metrics
Language — Total Work Hours
- C — 26,273
- COBOL — 22,394
- Fortran — 22,394
- Lisp — 14,636
- C++ — 12,697
- Java — 12,697
- Python — 12,697
- C# — 12,309
- Ruby — 11,312
- Delphi — 8,289
- Objective-C — 7,848
- Smalltalk — 6,879
Even much-hyped languages like Go, Dart, Elixir, Haskell, and Julia don’t fare as well as Smalltalk.
(First published at Hackernoon.)