Robert C. Martin (“Uncle Bob”) has a new fetish: Clojure. From this article, I quote something that I feel is necessary to clarify:
Smalltalk was small and elegant and beautiful. It spawned the Design Patterns revolution. It spawned the Refactoring revolution. It spawned the TDD revolution. It helped to spawn the Agile revolution. Smalltalk was a language of tremendous impact.
Smalltalk was also an image based language. Very few programmers have ever wrapped their minds around what that really meant. So, unfortunately, the language languished compared to all the text-file based languages.
Lisp is older, by far, than Smalltalk or Forth. It was created in 1957 from concepts that came out of the ’30s) and it has never languished in the way Smalltalk and Forth have. Indeed, it’s the language that refuses to die. We’ve tried to kill it many times. But like the annoying neighborhood stray cat it keeps … coming … back.
First of all, to say that Lisp has never languished is patently false. Since its heyday in the 1970s and 1980s when Lisp was touted as the ultimate AI language, Lisp has been largely ignored until Clojure came onto the scene in 2007.
Meanwhile, Smalltalk has never languished. Sure, it was no longer a prominent IT language after Java came onto the scene in the late 1990s, but Smalltalk has continued to be an important enterprise language supported by no fewer than three major commercial Smalltalk vendors! How many commercial Lisp vendors are there? Franz (Allegro) and LispWorks come to mind but these are relatively insignificant corporations.
In 2008, a new open source Smalltalk arrived on the scene called Pharo. It was contemporary with Clojure! But whereas Clojure was intimately tied to the Java ecosystem, Pharo was more independent and flexible.
One final remark about Smalltalk’s image-based development model… It’s not so hard to wrap your mind around it since it is very similar to other models that everyone uses:
- Docker containers
- virtualization software such as VMware and VirtualBox
There is practically no difference, for example, between a Pharo image and a Linux virtual system image that contains a Java application along with its Java IDE and support libraries. Both can have their execution state saved and restored.
The big difference, of course, is that the Pharo image supports live programming. (Java can support live programming, sort of, through HotSpot technology but it is neither standard nor convenient.)
And, by the way, Lisp is also image-based. Clojure broke away from this to use the JVM. But Lisp images aren’t used to the same extent as in Smalltalk.
On a personal note… Though I admire both Lisp and Smalltalk for their small size and syntactical elegance, I find Lisp syntax more off-putting. The mountains of parentheses are hard on the eyes. The prefix notation makes arithmetic expressions look bizarre, e.g., 3 * 4 + 5 looks like (+ (* 3 4) 5). And the use of special forms make Lisp a more complex language.
Uncle Bob also says:
Finally, Lisp is functional. And the future is looking very functional to me.
Well, Smalltalk is also functional in addition to being object-oriented. Sure, it’s not primarily functional but Smalltalk’s blocks can and are used in many functional ways.
Uncle Bob also admits something in an earlier article that I’ve been harping on for years: that Smalltalk programming is supremely productive.
But to set the stage I have to tell you about the research done by Capers-Jones regarding the productivity of programmers using different languages. His study showed that
Smalltalk
programmers were much more productive thanC++
programmers. Some people thought the difference was as much as 5X. Others thought it was more like 2X-3X. But nobody thoughtC++
programmers were more productive than Smalltalk programmers.
In fact, Capers Jones’ study shows that Smalltalk is the most productive of all the major programming languages, easily beating out JavaScript, Lisp, C++, Go, Java, Python, C#, Dart, Ruby, Elixir, Haskell, and Julia.

If programming productivity is vital to you, then Smalltalk/Pharo is easily the superior choice to Clojure.