Elixir as an Object-Oriented Language(tech.noredink.com)
tech.noredink.com
Elixir as an Object-Oriented Language
http://tech.noredink.com/post/142689001488/the-most-object-oriented-language
10 comments
This sort of article and the sort of thinking underpinning it is a betrayal of the uniqueness (relative to the more ``mainstream'' choices) of languages like Elixir/Erlang. In fact, part of the point of using a language like Erlang or Go (besides more production-relevant claims to fame like reliability or build times respectively) is to break one's thinking out of the object-oriented lens.
Not every abstraction is object-orientation. The notion of not caring about the internals of something (as with the article's mention that "This is possible because Elixir doesn’t care how the process works internally") is something that goes deeper conceptually and further back in time than objects as we know them.
It might be neat for weaning someone off an overwhelmingly OOP mindset, but that's not what it seems to be trying to do. Instead, it's just demonstrating how to use a new language without it forcing you to think differently, and that's worrying. If every language is a fantastic object-oriented language, why bother using any given one?
Not every abstraction is object-orientation. The notion of not caring about the internals of something (as with the article's mention that "This is possible because Elixir doesn’t care how the process works internally") is something that goes deeper conceptually and further back in time than objects as we know them.
It might be neat for weaning someone off an overwhelmingly OOP mindset, but that's not what it seems to be trying to do. Instead, it's just demonstrating how to use a new language without it forcing you to think differently, and that's worrying. If every language is a fantastic object-oriented language, why bother using any given one?
This entire article is about Elixir, not Erlang. Can someone fix the submission title?
Also this fits with my experience with Elixir. I can apply all my OOP baggage very well in Elixir; one active process maps beautifully one object.
The only thing I miss is a clear _terminology_ distinction between the Elixir versions of an object and a class. Both are called processes, which is a bit messy. Strictly a process is just the runtime thing (the "object") and the "class" is just a function (or, in practice, a module that follows a certain convention). But I've heard many people refer to the latter as "processes" too and I'd love a better word.
Also this fits with my experience with Elixir. I can apply all my OOP baggage very well in Elixir; one active process maps beautifully one object.
The only thing I miss is a clear _terminology_ distinction between the Elixir versions of an object and a class. Both are called processes, which is a bit messy. Strictly a process is just the runtime thing (the "object") and the "class" is just a function (or, in practice, a module that follows a certain convention). But I've heard many people refer to the latter as "processes" too and I'd love a better word.
> This entire article is about Elixir, not Erlang. Can someone fix the submission title?
The article uses Elixir examples, but it is fundamentally about Erlang as that's where the understanding of the concept comes from (through Joe Armstrong), and the examples could just as well have been in Erlang:
> There’s one moment in the episode that surprised me. Joe makes a comment about Erlang being “the most object-oriented language.” The same can be said of Elixir.
This applies to Elixir through Elixir being a syntactic layer over Erlang, not through anything otherwise intrinsic to Elixir.
The article uses Elixir examples, but it is fundamentally about Erlang as that's where the understanding of the concept comes from (through Joe Armstrong), and the examples could just as well have been in Erlang:
> There’s one moment in the episode that surprised me. Joe makes a comment about Erlang being “the most object-oriented language.” The same can be said of Elixir.
This applies to Elixir through Elixir being a syntactic layer over Erlang, not through anything otherwise intrinsic to Elixir.
The class is a module, usually a GenServer. The object is the process spawned from the module. There are no better words because Erlang is born functional and OO is maybe a dirty word in that world. People are starting to accept that it's somewhat object oriented only now. Maybe the next language to use BEAM will use the proper names for the object oriented part of the language. Btw, somebody is trying to make Ruby work on BEAM https://github.com/johnlinvc/erruby
Sooooo
A process is a function running in its own context.
A module is just a namespace to group some functions. But there is no real link to what an object brings.
At best you could try to compare an OTP behaviour to a class but even that...
A process is a function running in its own context.
A module is just a namespace to group some functions. But there is no real link to what an object brings.
At best you could try to compare an OTP behaviour to a class but even that...
A process is an object. It accepts messages and sends messages. It encapsulates state.
Sure. But... Then you enter the place where you get overloaded semantic. In particular... the fact that "Object need Classes !" or "Objects are a thing that encapsulate Functions with hidden state"
I have some ideas for post about the fundamental difference beetween RPC and message passing. And how it impact how you think about your code (Java/Cpp vs Smalltalk/Erlang). I think it is the main point.
I have some ideas for post about the fundamental difference beetween RPC and message passing. And how it impact how you think about your code (Java/Cpp vs Smalltalk/Erlang). I think it is the main point.
> In particular... the fact that "Object need Classes !"
That could hardly be less of a fact though.
That could hardly be less of a fact though.
Alan Kay, When he first created his OO language, SmallTalk 72, It didn't have classes, or Inheritance. That development came later in Smalltalk 80. The only thing that Kay cared about was encapsulated code that could pass messages around to other encapsulated code.
Kay's thoughts on the matter are in the link below.
http://programmers.stackexchange.com/questions/46592/so-what...
I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind
-- Alan Kay, OOPSLA '97
Kay's thoughts on the matter are in the link below.
http://programmers.stackexchange.com/questions/46592/so-what...
I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind
-- Alan Kay, OOPSLA '97
I gave a talk on OOP and what I think Alan Kay was really talking about WRT OOP http://brianknapp.me/message-oriented-programming/
You sir are doing the talk i want to keep doing for the Elixir Community. I sometimes wonder if we do not need a way to talk about this type of thinking more publically...
Also who ever changed the title, It's "Erlang - The Most Object-Oriented Language," as per the quote in the article!
-- "Joe makes a comment about Erlang being “the most object-oriented language.”"
If you are going to Change it At least change it to "Elixir - The Most Object-Oriented Language"
If you are going to Change it At least change it to "Elixir - The Most Object-Oriented Language"
Somewhat related, there was a fun Lightning Talk at ElixirConfEU, "Advanced OOP in Elixir" - https://www.youtube.com/watch?v=5EtV2JUU0Z4
I feel like stepping the reader through creating a whole Mix project was a little bit excessive. Was a simple code snippet demonstrating a process or two (and maybe a module or two) really insufficient for that?
Otherwise a good read. The idea of Elixir/Erlang being "object-oriented" by way of their application of the actor model was one of the "eureka" moments in my transition from procedural languages (in particular, Ruby).
Otherwise a good read. The idea of Elixir/Erlang being "object-oriented" by way of their application of the actor model was one of the "eureka" moments in my transition from procedural languages (in particular, Ruby).
This is of course not true, but PR. Here's what Joe wrote once:
"When I was first introduced to the idea of OOP I was skeptical but didn't know why - it just felt "wrong". After its introduction OOP became very popular (I will explain why later) and criticising OOP was rather like "swearing in church". OOness became something that every respectable language just had to have.
As Erlang became popular we were often asked "Is Erlang OO" - well, of course the true answer was "No of course not" - but we didn't to say this out loud - so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully)."
http://web.archive.org/web/20020413132000/http://www.bluetai...
"When I was first introduced to the idea of OOP I was skeptical but didn't know why - it just felt "wrong". After its introduction OOP became very popular (I will explain why later) and criticising OOP was rather like "swearing in church". OOness became something that every respectable language just had to have.
As Erlang became popular we were often asked "Is Erlang OO" - well, of course the true answer was "No of course not" - but we didn't to say this out loud - so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully)."
http://web.archive.org/web/20020413132000/http://www.bluetai...
Well, Armstrong may have been exposed to C++-style OOP like many (most?) programmers, which would of course lead him to believe that Erlang was very different from C++'s OOP. But languages that really orient toward object orientation rather than a thin semantic layer over procedural programming look a lot more like Erlang. Take Smalltalk for example: Smalltalk objects talking to each other looks almost identical to Erlang threads talking to each other.
Erlang uses asynchronous message passing. Smalltalk models method calls as synchronous message passing. Therein lies an enormous amount of difference.
Yes, it absolutely is. But I do understand what imagist is getting at; if you read about what Smalltalk is supposed to be and you read Alan Kay's description of what OO is supposed to be, but you don't use Smalltalk yourself, it is easy to think that Erlang is exactly what he was talking about.
I assume this comes down to a basic equivocation about what "message" really means. In English, it is an asynchronous communication. Whether Alan Kay meant it synchronous, asynchronous, or didn't care, I don't know. But it has never been terribly mysterious to me that the "message passing" in Smalltalk turned into "method calls" in almost every other implementation. I couldn't even tell you what the difference between synchronous message passing and a method call is. Possibly back in the day (had I been around) I could have. But what with all the languages nowadays that have all sorts of semantics for "method calls" you can choose from, I wouldn't know where to draw a line today.
Erlang-style message passing looks to me to be more like what Alan Kay's words were than even Smalltalk was.
Related: https://vimeo.com/108441214
I assume this comes down to a basic equivocation about what "message" really means. In English, it is an asynchronous communication. Whether Alan Kay meant it synchronous, asynchronous, or didn't care, I don't know. But it has never been terribly mysterious to me that the "message passing" in Smalltalk turned into "method calls" in almost every other implementation. I couldn't even tell you what the difference between synchronous message passing and a method call is. Possibly back in the day (had I been around) I could have. But what with all the languages nowadays that have all sorts of semantics for "method calls" you can choose from, I wouldn't know where to draw a line today.
Erlang-style message passing looks to me to be more like what Alan Kay's words were than even Smalltalk was.
Related: https://vimeo.com/108441214
That is an enormous amount of difference, but one which seems entirely irrelevant to Kay's description of object-orientation.
In fact, asynchronous messaging seems more in the spirit of "objects being like biological cells and/or individual computers on a network" than a smalltalk-style synchronous message stack.
In fact, asynchronous messaging seems more in the spirit of "objects being like biological cells and/or individual computers on a network" than a smalltalk-style synchronous message stack.
My personal opinion is that Smalltalk's biggest mistake was making message sends synchronous.
Agreed, that is an enormous difference, but is that difference material to the definition of OOP? I tend to think it isn't.
Question about elixir: In the article's example, it looks like the HTTP.get function call is turning the asynchronous message into a blocking call. Is that common in elixir/erlang, for libraries to provide blocking utilities?
> Is that common in elixir/erlang, for libraries to provide blocking utilities?
It's very common to have blocking API as that's convenient and better hides the implementation details of the API.
Note that the blocking is completely local, it'll simply yield back to the scheduler and some other process will get to run (and BEAM is preemptive so after a number of operations — reductions in BEAM parlance — it's going to deschedule the current process and let something else run even without IO calls).
And of course you can trivially "unblock" the call by creating a wrapper process for that call.
It's very common to have blocking API as that's convenient and better hides the implementation details of the API.
Note that the blocking is completely local, it'll simply yield back to the scheduler and some other process will get to run (and BEAM is preemptive so after a number of operations — reductions in BEAM parlance — it's going to deschedule the current process and let something else run even without IO calls).
And of course you can trivially "unblock" the call by creating a wrapper process for that call.
Yes, it's quite common for Elixir libraries to provide blocking calls. If your program is well-designed though, the calling process will be "blocked" but other processes will be executing at the same time. So having a process waiting on a HTTP call has no impact on the overall performance of the system. This is one of the big reasons why Erlang/Elixir's model of having many processes is awesome.
It's also very easy to use the async/await pattern if you want to make a call, do other work, and get the data from the call at some later point.
It's also very easy to use the async/await pattern if you want to make a call, do other work, and get the data from the call at some later point.
Looks unreadable https://i.imgur.com/MTJziXw.png
Works in Safari Technology Preview 12 on Mac OS 10.11.6: http://i.imgur.com/cdN7ky2.png
Seems to work just fine on all OSX browsers (latest stable Chrome, Firefox and Safari)
That said, I think the real value of Erlang is the actor model, and specifically, the way it causes you to model things and concepts (or objects, but without the baggage) as isolated processes. This is a direct parallel to the kingdoms of verbs and nouns, but, many OO languages provide isolation for their objects/things/nouns, but not for the processes/verbs. Or rather, the process is not naturally related to the noun, but rather almost an Aspect Oriented programming approach. The actual execution crosses the boundaries of the objects/things/nouns (i.e., a single object's instance being accessed by multiple threads, all contending to modify it; the verbs span the boundary of the noun). But in the actor model, that doesn't happen; you have proper isolation of state (the thing/noun/etc) in the actor, but also isolation of execution (the process/verb) in the actor. That is, one actor = one isolated chunk of both state AND execution.
It's this model that people are looking at when they say it's better at object orientation. I think that's a bit misleading (per other comments), but there's real benefit to it.