Today I stumbled across “Guidelines for Choosing A Computer Language: Support For The Visionary Organization” by Patricia K. Lawlis, written back in 1997.
Appendix Q deals with Smalltalk. Here are the categories in which Smalltalk scores well:
- Clarity of source code - Rating: 9
- Complexity management (architecture support) - Rating: 6
- Maintainability - Rating: 7
- Object-oriented programming support - Rating: 10
- Reusability - Rating: 8
- Support for modern engineering methods 1 - Rating: 7
Here are the categories in which Smalltalk scores poorly:
- Concurrency support - Rating: 2
- Distributed system support - Rating: 0
- Mixed language support - Rating: 3
- Portability - Rating: 3
- Real-time support - Rating: 0
- Reliability - Rating: 3
- Safety - Rating: 0
- Standardization - Rating: 3
Those low scores are ripe for correction!
People often speak of Smalltalk as if it were just another programming language. It is that, of course: Smalltalk the language is pure-object-oriented, class-based, memory safe, reflective, and dynamically typed. However the same name, Smalltalk, also denotes a complete operating system in a virtual machine on top of a traditional OS. Smalltalk’s operating-system nature is to blame for its poor performance in the categories shown above.
The (implied) criticisms of the low scores above are absolutely spot on:
Smalltalk’s support for concurrency (isolation of processes; management of processes; isolating failures; transactional behaviour; etc.) is very low-level and old fashioned. Exactly what one would expect from an operating system designed in the early 80s.
Its support for distributed programming is also not great. (I have a hypothesis about why that is, that I’m researching at the moment.)
No isolation between processes makes mixed language support difficult.
Reliability and safety are nonexistent in an environment with no isolation boundaries.
Smalltalk is a heavily imperative language. Data structures are mutated internally all over the place, giving a straightforward shared-memory concurrency model.
Erlang’s support for concurrency is very strong. Processes are, by default, isolated from one another, in that they share no mutable state, and a failure in one process cannot affect another process in an unstructured way.
Its support for distributed programming is also very strong. Processes communicate by shared-nothing message passing. Scaling from a non-distributed system to a distributed system starts with the simple substitution of a TCP socket for an in-memory message queue.
Isolation between processes makes the decision of which language to use to handle received messages within a process an essentially arbitrary one, though in practice Erlang doesn’t support anything other than its built-in functional fragment.
Reliability and safety follow from the strong isolation boundaries between system components and from the structuring principles embodied in the OTP libraries.
Erlang is a heavily functional language. Data structures are immutable, giving a straightforward shared-nothing message passing concurrency model.
Erlang has its problems, of course: it doesn’t support object-oriented programming other than either awkwardly (processes look a bit like objects) or in a trivial sense (function closures and objects are the same thing). As a result, generic programming (e.g. ignoring whether you have a list of numbers or an array of numbers) is poorly supported, syntactically unpleasant, and/or slow. It also enjoys none of the rich reflective support provided by the Smalltalk virtual machine, which makes the monitoring tools feel ad-hoc and not very general.
My instinct is that a system that supported a combination of Smalltalk’s smooth generic and reflective programming styles and Erlang’s ability to construct robust, concurrent and distributed systems, would make a great foundation for personal computing.
What can be done to Smalltalk’s operating-system nature to improve isolation of components within a running system? Mutability is a key concern, as is failure isolation. Can Smalltalk be refactored into a hybrid Smalltalk-Erlang system?