The OOP Concept according to Erlang

To me an OOPL has the following properties:

  • Isolated objects (= Erlang processes) - if one process can in any way damage another object then you cannot write decent code

  • Polymorphic (example you could send a “print_yourself” message to any
    process and it would know how to deal with it - this makes life easy for the the programmer) -

  • Late binding (You can send a message to a process, and send code to a process, provided the code gets their first, everything is fine)

  • Dynamic (possible to evolve in a biological sense) - keeping the entire world strongly consistent (in the sense of a strict type system) is impossible - even types change with time - in live systems the code must be able to evolve.

All this stuff about classes and methods is “just” a way of defining and grouping
abstract data types.

Inheritance is just a hack - in Erlang/Elixir you can just send a message down a
chain of processes until somebody recognises it.

In my opinion Erlang/Elixir/Pony etc are the only languages which can be called
OO.

Java/C++/Smalltalk do not protect objects - send a “message” (or evoke a method) that leads to an infinite loop and you screw up the system.

Erlang/Elixir are rather nice send a message to a process that sends the process into an infinite loop and you won’t even notice it.

And yes you can break beam code - but you have to try hard.

Alan Kay was right - “it’s all about messages” (as was Carl Hewitt)

Cheers

/Joe

33 Likes

Object Orientation isn’t some kind of gold standard that one has to aspire to “to become one” with the “one true way”. I’ve always viewed it as a set of heuristics that attempt to manage complexity (with a different kind of complexity).

For insights into “the world according to Erlang (BEAM)” I’d recommend putting objects (and more importantly classes) aside for a moment and watch

Now some people in other areas are trying to advance OO like Trygve Reenskaug and Jim Coplien with DCI - Data Context Interaction (though a lot of it seems to revolve around the idea that today there is too much focus on programming and not enough on analysis and design in order to minimize accidental complexity early).

6 Likes

The sending messages is big for me. Learning Smalltalk first and then Ruby I always wondered why everyone talked about sending message “that objects would choose how to handle” - yet you never get the message itself (yes yes method_missing, yes yes).

In erlang you actually get access to the message and could actually drop it if you wanted to or whatever :smiling_imp: Hence it is philosophically closer to what is described in OOP in that sense. Or well not just erlang but actor-like systems in general.

Funny thing I mentioned this when discussing Actor systems in university and that I felt they’re kinda even “more OOP than OOP” but my lecturer stopped me from sprouting such nonsense :wink:

Classes etc. are also just to make objects work… it’s called Object Oriented Programming after all, not Class Oriented Programming.

@peerreynders Jim has been on DCI for a while… I find the idea interesting but haven’t seen it take off in practice. For me the core of DCI is more that lots of interactions are contextual and lots of code is only ever used/needed in specific contexts while it usually lives together in big objects which is counter productive. As such it can also be used as a guidelines for better design imo :slight_smile:

1 Like

Not sure about any Erlang projects, but some longer time ago I have found this awesome Elixir library:

It’s not a really big repository, so it should not be a bigger problem even for beginner to rewrite it to Erlang.

You just can’t resist can you … April 1 isn’t that far off!

Because of Multi-Paradigm Design I like to keep track of him and the shift towards roles rather than classes seems interesting. In any case his talks like What went wrong with the IT-industry? are entertaining at least, if opinionated.

1 Like

Thanks for the talk suggestion, I’ll put it on to watch. Jim is interesting/opinionated/polarizing. As I said I found DCI to be interesting, didn’t quite appreciate the way he conducted himself at the conference though - taking on stage time to make fun of a bug in the conference website (it was only visible in the university internal network) isn’t exactly something I appreciate :woman_shrugging:

But yeah, seemingly being controversial/brash helps your popularity more than presenting well balanced opinions :expressionless:

Via the links I found https://www.goodreads.com/book/show/8739006-lean-architecture. Also see the not too positive bookreviews. Not my cup of tea this book.

I would also like to point out that the term OOP has two completely different meanings:

  1. The notion of Objects comes from Simula and the work of
    Ole-Johan Dahl and Kristen Nygaard - this introduced the ideas of
    objects, classes and inheritance.

  2. The term Object Oriented Programming was coined by Alan Kay and was much
    more concerned with the idea of sending messages between isolated objects

You might like to take a look at

Which has a reasonably good summary

When we were developing Erlang @rvirding and I read every book we could find that described OOP and came to the conclusion that there were no definitive descriptions of what an OOPL was it was more a case of “you can recognise an OOPL when you see one”.

The first Erlang book had a chapter on OOP – this was actually a joke – but nobody realised this …

Objects in the early 90’s were a very “sellable” – Salesmen in snake-skin suits pitched stories of “inheritance” to management - “write once” then once you have your code base you can make new solutions based on the old ones by “reusing your code”

The idea was pitched that “all you had to do was rewrite everything in C++ and make a code base of stuff you could inherit” and you could fire most of your programmers and reduce your software costs to near zero - didn’t happen like this though. (But it took ten years to discover this :-))

I had always (and still) viewed this reuse stuff as total nonsense - functional re-use is possible but the non-functional properties of a program cannot be re-used.

If a program is slow/big - then an inherited version of the program will be slow/big

If a program is buggy the inherited program will be buggy …

I talked to Alan Kay on several occasions about this - he likes Erlang but he’d like it even more if it were bundled into a single quine like system (like smalltalk)

Cheers

15 Likes

Stroustrup talks about OOP without inheritance:


Removing inheritance is one of the things I do when refactoring an OO codebase.

2 Likes

I don’t know if this fits in here to 100%. But in this great talk Scott Wlaschin compares OOP patterns with FP.


Before watching, try to make a guess what is the equivalent FP pattern to each OOP pattern.

@PragTob You are so right and it is always tricky to discuss this with people they just have one paradigm.

3 Likes

That highly reminds me of a book I want to re-read/a book that helped improve my ruby code a lot at the time: Functional Programming Patterns in Scala and Clojure - can recommend it to everyone using a multi paradigm language or people new to elixir/FP :slight_smile:

Wow! It’s an honor to hear from you! Enlightening! Thanks!!!

2 Likes

Gracias!!!

I love that we have Erlang royalty here :003:

:heart:

3 Likes

I know we’re going a bit off topic here, but it’s honestly super great of them to be around and occasionally answer things like these which is super enlightening - I still remember that on one of my first posts about TCO @rvirding chimed in :green_heart:

Of course doesn’t only go for the erlang peeps but also José, Michał and all the other “implementors” being very helpful around here. For erlang peeps it’s especially nice because this isn’t the “erlang forum” (although it kinda is :slight_smile: ). Love it when communities work together closely.

4 Likes

Interesting, but IMHO we are always going to reinvent the wheel as the knowledge gets lost among the tens of thousands of objects/functions (the bigger the code base, the worse it becomes…). So even if functions with no side effects are more reusable in theory, does it really matter in practice?

Yep, they’re awesome :003:

I kindof see them as our granddaddies - not because of age or anything like that, but in the sense that Erlang is a parent of Elixir, and we, the community, are Elixir’s own children :lol:

Grandparent-grandchild relationships are always special imo, and it’s clear to me that so many of us hold Robert, Joe, Mike and the rest of the Erlang crew in such high regard. I sincerely hope they feel that love and I also hope we are doing them proud, and that whenever they see us or Elixir doing well, that they feel immensely proud themselves, because we are a part of their family and ultimately, whenever anyone thinks Elixir, they also think Erlang :blush::heart::purple_heart::heart:

2 Likes

I actually had an opportunity to ask Alan Kay about current developments of OOP and the original definition being much more closer to Erlang than anything else we commonly see.

His response seems to line up with our community’s thoughts on the topic:

7 Likes

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.

3 Likes

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