The Weaknesses of Smalltalk are the Strengths of Erlang

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.

So what can be done? Let’s look at another Application Operating System2, this one designed with fault-tolerance in mind: Erlang/OTP.

  • 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?

  1. Bear in mind that the document was written in 1997, so what “modern engineering methods” meant then is unlikely to line up well with what the term means now.

  2. Joe Armstrong defines Erlang/OTP as an “Application Operating System” on page 9 of his PhD thesis.

Comments (closed)
Dennis Schetinin 12:41, 9 May 2011

"Its support for distributed programming is also not great. (I have a hypothesis about why that is, that I'm researching at the moment.)" — can you please explain what's so bad about OpenTalk?

Tony Garnock-Jones 13:41, 7 Jun 2011

This is the first time I've heard of OpenTalk. It looks like a VisualWorks-only thing, which is a shame, coming from a Squeak perspective as I do. With the caveat that I've never used OpenTalk, it seems to me like a straightforward lightweight RPC system. Such can be constructed for arbitrary languages—even C—which puts it in a different category from integrated language and library level support for distributed programming, as is seen in Erlang.

There's nothing particularly wrong-seeming about OpenTalk or the other similar systems out there (Java RMI, CORBA, etc.), as far as they go, but the way they choose what gets sent by value and what by reference is ad-hoc, and issues of concurrency, directory, reliable messaging, transactionality, garbage collection, fault isolation, security etc are all solved in ad-hoc ways as well.

A person 06:30, 20 Oct 2011

I get what you are saying, but most of Erlang's lack of generic programing support mostly is because it is old, and dynamic.  Newer functional languages like Haskell (or even ML) implement a lot of features thought to be exclusive to OOP in a context relevant to functional programming. (I think that Haskell and ML share a lot of strengths with Ada as far as the scoring of that rubric goes, since they have a lot of large scale programming features)  I think parametric polymorphism made its debut in ML, for example.  None of the dynamically typed FPLs seem to have those features though, oddly.  I guess OOP is more well suited towards such features insofar as dynamic languages go.

A person 06:34, 20 Oct 2011

That said I like Erlang a lot and use it (almost) every day.  I'd like to learn Smalltalk as well.

Trevor Andrade 01:48, 1 Mar 2014

How about squeak E.

Tony Garnock-Jones 10:00, 1 Mar 2014 (in reply to this comment)

It's definitely several steps in the right direction!