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.
