I remember before I was able to read/see something about the concept of OOP in Erlang which was different from the current conventional OOP.
Would anybody care to share some links or talk?
Thanks!
3 Likes
Maybe you’re thinking about what Alan Kay said: Dr. Alan Kay on the Meaning of "Object-Oriented Programming"
Specifically:
I thought of objects being like biological cells and/or individual
computers on a network, only able to communicate with messages (so
messaging came at the very beginning – it took a while to see how to
do messaging in a programming language efficiently enough to be
useful).
Since Erlang uses messaging to communicate between processes, this seems like a very apt description of the language.
4 Likes
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
35 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 
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 
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 
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 
But yeah, seemingly being controversial/brash helps your popularity more than presenting well balanced opinions 
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:
-
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. -
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
17 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
Wow! It’s an honor to hear from you! Enlightening! Thanks!!!
2 Likes
Gracias!!!
I love that we have Erlang royalty here 
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 
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 ). 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
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 
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 
2 Likes
