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).
(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.
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.
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.