2 ms·

> I mean, if you're writing Erlang/Elixir code, then you kind of do have "classes, instances, and ancestors" and > In short: I think it's only an accident of

> I mean, if you're writing Erlang/Elixir code, then you kind of do have "classes, instances, and ancestors" and > In short: I think it's only an accident of history (of Elxiir copying Erlang's delegate-module approach to receive-selector "inheritance", instead of going for a macro-based approach) that held Elixir back from blossoming into an ecosystem of "stupid OOP tricks" that are just as messy and ridiculous as Ruby's. Directly contradict each other unless you ignore what I wrote.

deleted 3y ago
[deleted]
derefr 3y ago
Let me restate my points succinctly: 1. OTP behaviors are OOP classes. And individual gen_* processes are instances of those classes. And those instances have proc_lib as an ancestor. So in a very literal sense, Erlang and Elixir have "classes, and instances, and ancestors." 2. But the few existing OTP behaviors are — idiomatically — literally all you get. Insofar as you're using the OTP framework, you don't get to define any of your own "classes." There's just the five that OTP comes with. And proc_lib is the only ancestor. 3. But that doesn't mean that the runtime-level potential for "first-class OOP" with all its quirks isn't there; especially in Elixir. Just because nobody has bothered to exploit it, doesn't mean that doing so wouldn't be possible. And, more oddly — just because the features go mostly unused, doesn't mean that it'd be possible to refactor the Erlang runtime to in any way remove those capabilities. They're inherent to the design of both Erlang and Elixir — even if it's only those six little "classes" that make use of them. Which directly addresses your point: > I don't use any of that stuff now and I write pretty much the same software I did back then. You do still use "that stuff" (under other names, in a very formalized and circumscribed capacity.) A language that truly prevented you from doing any kind of OOP, no matter how under-the-covers, really wouldn't let you write the same sort of software!
- krainboltgreene 3y ago
  You're certainly welcome to think these things, but you're going to have to take it up with Joe Armstrong, because he definitely didn't believe Erlang have "classes, instances" and while you're right that on a technical level you can share behavior from one module to another, it's absolutely not the same as Ruby's inheritance logic.

deleted 3y ago

[deleted]

derefr 3y ago

Let me restate my points succinctly: 1. OTP behaviors are OOP classes. And individual gen_* processes are instances of those classes. And those instances have proc_lib as an ancestor. So in a very literal sense, Erlang and Elixir have "classes, and instances, and ancestors." 2. But the few existing OTP behaviors are — idiomatically — literally all you get. Insofar as you're using the OTP framework, you don't get to define any of your own "classes." There's just the five that OTP comes with. And proc_lib is the only ancestor. 3. But that doesn't mean that the runtime-level potential for "first-class OOP" with all its quirks isn't there; especially in Elixir. Just because nobody has bothered to exploit it, doesn't mean that doing so wouldn't be possible. And, more oddly — just because the features go mostly unused, doesn't mean that it'd be possible to refactor the Erlang runtime to in any way remove those capabilities. They're inherent to the design of both Erlang and Elixir — even if it's only those six little "classes" that make use of them. Which directly addresses your point: > I don't use any of that stuff now and I write pretty much the same software I did back then. You do still use "that stuff" (under other names, in a very formalized and circumscribed capacity.) A language that truly prevented you from doing any kind of OOP, no matter how under-the-covers, really wouldn't let you write the same sort of software!

krainboltgreene 3y ago
You're certainly welcome to think these things, but you're going to have to take it up with Joe Armstrong, because he definitely didn't believe Erlang have "classes, instances" and while you're right that on a technical level you can share behavior from one module to another, it's absolutely not the same as Ruby's inheritance logic.