Smalltalk vs Scheme, JavaScript, and Java


Smalltalk is an amazing language. It’s the perfect instructional language for teaching programming to both children and adults alike. It’s very easy to learn and extremely versatile, rather like JavaScript but without all the rubbish that JavaScript imposes on hapless programmers. Smalltalk compares well with Java when it comes to writing solid, large-scale software, despite being dynamically typed.

In this article, I shall highlight the key differences between Smalltalk and Scheme for instructional purposes, and between Smalltalk and JavaScript for safety and usefulness, and between Smalltalk and Java for heavy-duty industrial programming.

Scheme

Smalltalk was expressly designed by Alan Kay for teaching programming to children. It’s perfect for adults, too. Smalltalk is very clean, simple, and elegant. It virtually has no syntax!

But Smalltalk isn’t the only language that has these qualities. For many years, MIT taught programming to freshmen using Scheme and its excellent companion book, “Structure and Interpretation of Computer Programs,” affectionately known as SICP (pronounced “sick-pea”). They chose Scheme precisely for its simplicity so that the language gets out of the way of the beginner. Like Smalltalk, Scheme has no distracting features and baggage that carries over from industrial use.

However, the two languages have interesting differences. For one, Scheme’s syntax is plagued by endless parentheses that can obscure readability. Scheme’s relentless functional prefix notation can be awkward (esp. for arithmetic, relational, and logical operators). For example,

;;; make-matrix creates a matrix (a vector of vectors).
(define make-matrix
(lambda (rows columns)
(do ((m (make-vector rows))
(i 0 (+ i 1)))
((= i rows) m)
(vector-set! m i (make-vector columns)))))

Smalltalk, on the other hand, reads almost like natural language, thanks to its use of unary, binary, and keyword messages: read my seminal article on Smalltalk entitled “How learning Smalltalk can make you a better developer.”

Another major difference is that Scheme is heavily functional in nature, whereas Smalltalk is purely class-based object-oriented. While classes and object-oriented programming (OOP) can be simulated in Scheme, it is not entirely a comfortable fit, just as functional programming can be simulated in Smalltalk but in a rather inelegant fashion.

There’s a good reason why Smalltalk is widely regarded as the premier OOP language, one that nearly all other languages seek to emulate (Java, Python, JavaScript, C#, C++, PHP, Ruby, Objective-C, Perl, Scala, Groovy, Dart, CLOS, Swift, etc.). When it comes to OOP, it would be a sin not to know Smalltalk.

Smalltalk is also a very practical language. It has been used commercially for over three decades and is still going strong. Scheme, on the other hand, is hardly used anywhere. Its big brother, Common Lisp, enjoys some commercial application, but only Clojure (a “Lispy” language) can be regarded as a strong enterprise programming language.

JavaScript

The creator of JavaScript claims that it was directly inspired by Scheme. Evangelist Douglas Crockford calls JavaScript “Lisp in C’s clothing.” But the truth is, JavaScript does not resemble Lisp nor Scheme in any significant fashion:

  • JavaScript’s C-like syntax robs the language of Scheme’s clean, elegant notation.
  • Lisp’s central data structure is the list. JavaScript doesn’t have a list data type. JavaScript’s central data structure is the associative array, which often masquerades as some other data type.
  • Lisp is homoiconic, i.e., its code and its data have the same primary representation. JavaScript is not. Not even a little bit.
  • Lisp’s homoiconicity provides for a powerful macro system. JavaScript does not have macros.
  • Lambdas do not make JavaScript Lisp-like, any more than C++, Java, Python, Haskell, and Smalltalk are Lisp-like.

JavaScript was also directly inspired by Self, a language based on object prototypes. This is a very unusual way to deal with OOP. JavaScript proponents describe prototypes as a powerful and wondrous way to program. However, object prototypes are so wonderful that no other programming language of note in the past 30 years has adopted them, except for Lua. Everybody else prefers object classes.

As I indicated earlier, Smalltalk is the premier object-oriented language. Even with ECMAScript 2015’s syntactic sugar for classes, JavaScript doesn’t hold a candle to Smalltalk for object-oriented programming.

JavaScript is enormously popular for web development, but not for the reasons you may think. JavaScript is the only language supported in the web browser, so web developers have no choice but to use it. On the basis of technical merit, just about any other programming language is preferable. Fortunately, there is a workaround: you can use languages that transpile to JavaScript. Amber Smalltalk is one of the best examples of this.

Even on the server side where Node.js has been successful, there are better alternatives such as Go. I wrote about this in The Fall of the House of Node. Why inflict JavaScript upon yourself? (Incidentally, JavaScript is finding its way into other areas of IT such as desktop, mobile, Internet of Things, and games, but it’s not especially popular.)

JavaScript is well-known for its long list of “warts,” so I won’t belabour the point here. I’ll just give you a small sampling of the nonsense that you need to put up with in this StackOverflow question. By contrast, Smalltalk has very few issues of contention and confusion, far fewer than any other language I know. It speaks well of Smalltalk’s beautiful design that after four decades since its introduction, Smalltalk remains as clean and pure as the driven snow.

Java

The main distinction between Java and Smalltalk is that one is statically typed and the other is dynamically typed. Otherwise, the two languages share a few things:

  • both are object-oriented (OO) languages all the way through (except for Java’s primitive types)
  • both compile to byte code that execute in a virtual machine; both are garbage-collected
  • both are extremely versatile, used in areas as diverse as web, desktop, mobile, robotics, Internet of Things, numerical computing, machine learning, etc.
  • both are quite capable of writing large and maintainable software systems

This last point is largely a matter of good project management, though the languages do offer excellent support for modularity and code organization. Java’s static typing offers a certain measure of safety but is otherwise not a panacea for managing large code bases. Some large Java projects have proven to be disastrous, while some large Smalltalk projects have been extremely manageable. A case in point is JWARS, a million-line battle simulation program written by the U.S. joint military in Smalltalk during the early 2000s. It even outperformed a similar simulation called STORM written by the U.S. Air Force in C++.

In fact, Smalltalk is so good for large enterprise systems that it almost became the enterprise standard programming language for today. In the early 1990s, IBM chose Smalltalk as the centrepiece of their VisualAge enterprise initiative to replace COBOL. IBM would not have made this decision if Smalltalk wasn’t up to the task of large-scale development. (Unfortunately, this role was eventually usurped by an upstart language called Java, which was well-marketed by Sun Microsystems.)

It should be noted that Java makes OOP much more complicated than in Smalltalk. This is also why Java is so verbose. Smalltalk’s OO concepts are exceedingly clean and simple. This makes OOP a pure pleasure. Not so much for Java.

If you’re a Java programmer and you’re curious about Smalltalk, this little primer may whet your appetite.