The OOP Concept according to Erlang

I’m beginning to suspect that Alan Kay’s object/message pronouncements are quoted outside of a larger context - in his case his Dynabook (1972)

As I understand it the vision was as “objects” as a user metaphor, a mental model for the visible things that can be interacted with on-screen. Granted that notion transferred to Smalltalk for straightforward mapping of (visual) user objects to code.

By their nature those (visual) objects probably relied heavily on the Dynabook runtime environment - the objects being the proverbial bananas supported by the Dynabook jungle.

IIRC in the 1990’s the Coad/Yourdon books

seemed to lean on simulating real world objects to justify the OO approach.

It’s shortly after that OO took on a life of it’s own, as a potential, universal problem solving/modelling approach. Therefore languages were quick to add classes

  • without the support of the equivalent of a Dynabook runtime environment
  • without the need to simulate real world objects

OO held on generally as strategy for organizing/partitioning code and as a means for encapsulation/information hiding.

However optimal partitioning is non-trivial so it is easy to get the (class/object) boundaries wrong and objects are not always the appropriate level of granularity for any one part.

So really Erlang or Elixir don’t have to be viewed in terms of OO as they choose to manifest the boundaries of their “parts” in a different manner:

  • functions
  • modules
  • processes

Not every problem solving/modelling approach has to be grounded in objects.

To spawn, or not to spawn? explores the kind of boundaries you have to deal with in Elixir and Erlang.


What I would like to see is an Elixir course that teaches the language from an OOP perspective.

I’ve read most of the PragProg books on Elixir and at best they make off-hand comments about similarities.

But it helps so much to have this fundamental assumption of processes being objects that respond to messages. And having things like Supervisor objects being your “main” object, etc.

1 Like