4 ms·

> You can’t design or understand real-world systems with this message-passing metaphor, it will only mislead you. Erlang disagrees. BEAM processes and its impl

> You can’t design or understand real-world systems with this message-passing metaphor, it will only mislead you. Erlang disagrees. BEAM processes and its implementation of a mailbox is probably the purest interpretation of Alan Kay's OOP, and you can indeed design and understand real-world systems using the actor model as implemented in the BEAM VM. In practice it's very simple to grasp, it's concurrent out of the box yet you never have to think outside the single thread.

codeflo 5y ago
I don't disagree that the actor model is useful. I just prefer to call it "the actor model", as you seem to do in your comment as well, instead of confusing it with what 99%+ programmers mean when they say "OOP". (Also, personal opinion: The "purest intepretation" of what Alan Kay had in mind in 1969 is Smalltalk. That's almost an objective fact: if he had something else in mind, he would have done it. I know that he says he had something like Erlang in mind from the very beginning, but to the best of my knowledge, those claims are retroactive.)
- rubyn00bie 5y ago
  > prefer to call it "the actor model", as you seem to do in your comment as well, instead of confusing it with what 99%+ programmers mean when they say "OOP". You’re totally missing the point. Erlang is more “message passing” than any OOP language I’ve ever used. It honestly just sounds like you’ve never used erlang since you immediately referenced actors.
  - codeflo 5y ago
    > You’re totally missing the point. Erlang is more “message passing” than any OOP language I’ve ever used. My point is that OOP is not about message passing. You say that Erlang is more about message passing than OOP languages are, aren't we exactly in agreement here? Also, it was the post I responded to that referenced actors, I'm not jumping to anything.
    - slver 5y ago
      Your problem is that you tried to argue that the original definition of OOP is not "helpful", because mainstream languages implement synchronous messaging. And to you synchronous messaging is not messaging. However (1) synchronous messaging IS messaging (2) we are moving to asynchrony. So the original definition of OOP is still the overarching theme of programming today, and it's quite helpful because those same mainstream messages are evolving to asynchrony, now as IO and cross-process and cross-machine communication has become the norm. Your limited mental model of objects just being structs with procedures works in the 90s, but it'll be detrimental when you design any system today, because you often need to be ready about asynchrony, redundancy, resiliency and non-immediate results at your module's boundaries. Basically you've focused too much on a few trees and you've missed the forest. But those trees are just happenstance, and the forest (the entire "OOP" with its implementation hiding, polymorphism and message passing) is the important paradigm and it's what everything is moving towards. At the low level, you can still think about objects as just Abstract Data Types. But that doesn't give you working systems at scale. It gives you just a set of data primitives to get started with.
      - codeflo 5y ago
        I'm not claiming that message passing has no role in distributed system design, of course it does. I'm just saying that message passing is not how OO languages typically work. To me, it seems like you're arguing that having a less accurate (I'm sorry, less "limited") understanding of actual language semantics (that it's just "message passing") somehow helps you design distributed systems. In my experience, the opposite tends to be the case.
        slver 5y ago
        Don't confuse language semantics with language implementation. Case in point SmallTalk does actually use message passing. So does Obj C and Swift. The compiler can often optimize those to either virtual or direct calls, because that's simply more efficient. And once again, synchronous message passing doesn't mean it's not message passing. You just gotta get your terms and frame right.
  - ProfHewitt 5y ago
    Erlang processes are an extension of the Actor abstraction that happens to support mailboxes, one-way messaging, and ability to update processes. Erlang programmers can be inefficient because Erlang itself does not directly support the Actor abstraction.
- ProfHewitt 5y ago
  The Actor Model is a unique-up-to-isomorphism model of the theory Actors. Lambda expression and Turing Machine differ in that each is defined as a particular kind of machine. Actors can perform computations that cannot be implemented by a nondeterministic Turing Machine. Also, an Actor application can be hundreds of times faster than any lambda calculus implementation. A programming language implementation is also a particular kind of machine. For example Smalltalk-71 was a byte code interpreter machine not based on Actors. See the following: https://papers.ssrn.com/abstract=3603021 https://papers.ssrn.com/abstract=3603021
eternalban 5y ago
(The hair in the ointment is the performance cost of message passing vs function calls.) Besides concurrency benefits of the actor model, message passing implicitly supports adaptive behavior. A message is, by definition, interpreted by the receiving actor. You can hot swap in Erlang precisely for this reason. "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet - to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. "If you focus on just messaging - and realize that a good metasystem can late bind the various 2nd level architectures used in objects - then much of the language-, UI-, and OS based discussions on this thread are really quite moot." http://wiki.c2.com/?AlanKayOnMessaging http://wiki.c2.com/?AlanKayOnMessaging So, it's this 'late binding' business -- the "interstitial" -- that is really interesting, powerful, and conceptually key to Kay's vision of organic systems. And this is basically reducible to one of the most powerful architectural concepts in software: indirection. https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar... Now curious as to which of these two first grasped the beauty of indirection in structures.

codeflo 5y ago

I don't disagree that the actor model is useful. I just prefer to call it "the actor model", as you seem to do in your comment as well, instead of confusing it with what 99%+ programmers mean when they say "OOP". (Also, personal opinion: The "purest intepretation" of what Alan Kay had in mind in 1969 is Smalltalk. That's almost an objective fact: if he had something else in mind, he would have done it. I know that he says he had something like Erlang in mind from the very beginning, but to the best of my knowledge, those claims are retroactive.)

rubyn00bie 5y ago
> prefer to call it "the actor model", as you seem to do in your comment as well, instead of confusing it with what 99%+ programmers mean when they say "OOP". You’re totally missing the point. Erlang is more “message passing” than any OOP language I’ve ever used. It honestly just sounds like you’ve never used erlang since you immediately referenced actors.
- codeflo 5y ago
  > You’re totally missing the point. Erlang is more “message passing” than any OOP language I’ve ever used. My point is that OOP is not about message passing. You say that Erlang is more about message passing than OOP languages are, aren't we exactly in agreement here? Also, it was the post I responded to that referenced actors, I'm not jumping to anything.
  - slver 5y ago
    Your problem is that you tried to argue that the original definition of OOP is not "helpful", because mainstream languages implement synchronous messaging. And to you synchronous messaging is not messaging. However (1) synchronous messaging IS messaging (2) we are moving to asynchrony. So the original definition of OOP is still the overarching theme of programming today, and it's quite helpful because those same mainstream messages are evolving to asynchrony, now as IO and cross-process and cross-machine communication has become the norm. Your limited mental model of objects just being structs with procedures works in the 90s, but it'll be detrimental when you design any system today, because you often need to be ready about asynchrony, redundancy, resiliency and non-immediate results at your module's boundaries. Basically you've focused too much on a few trees and you've missed the forest. But those trees are just happenstance, and the forest (the entire "OOP" with its implementation hiding, polymorphism and message passing) is the important paradigm and it's what everything is moving towards. At the low level, you can still think about objects as just Abstract Data Types. But that doesn't give you working systems at scale. It gives you just a set of data primitives to get started with.
    - codeflo 5y ago
      I'm not claiming that message passing has no role in distributed system design, of course it does. I'm just saying that message passing is not how OO languages typically work. To me, it seems like you're arguing that having a less accurate (I'm sorry, less "limited") understanding of actual language semantics (that it's just "message passing") somehow helps you design distributed systems. In my experience, the opposite tends to be the case.
      - slver 5y ago
        Don't confuse language semantics with language implementation. Case in point SmallTalk does actually use message passing. So does Obj C and Swift. The compiler can often optimize those to either virtual or direct calls, because that's simply more efficient. And once again, synchronous message passing doesn't mean it's not message passing. You just gotta get your terms and frame right.
- ProfHewitt 5y ago
  Erlang processes are an extension of the Actor abstraction that happens to support mailboxes, one-way messaging, and ability to update processes. Erlang programmers can be inefficient because Erlang itself does not directly support the Actor abstraction.
ProfHewitt 5y ago
The Actor Model is a unique-up-to-isomorphism model of the theory Actors. Lambda expression and Turing Machine differ in that each is defined as a particular kind of machine. Actors can perform computations that cannot be implemented by a nondeterministic Turing Machine. Also, an Actor application can be hundreds of times faster than any lambda calculus implementation. A programming language implementation is also a particular kind of machine. For example Smalltalk-71 was a byte code interpreter machine not based on Actors. See the following: https://papers.ssrn.com/abstract=3603021 https://papers.ssrn.com/abstract=3603021

eternalban 5y ago

(The hair in the ointment is the performance cost of message passing vs function calls.) Besides concurrency benefits of the actor model, message passing implicitly supports adaptive behavior. A message is, by definition, interpreted by the receiving actor. You can hot swap in Erlang precisely for this reason. "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet - to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. "If you focus on just messaging - and realize that a good metasystem can late bind the various 2nd level architectures used in objects - then much of the language-, UI-, and OS based discussions on this thread are really quite moot." http://wiki.c2.com/?AlanKayOnMessaging http://wiki.c2.com/?AlanKayOnMessaging So, it's this 'late binding' business -- the "interstitial" -- that is really interesting, powerful, and conceptually key to Kay's vision of organic systems. And this is basically reducible to one of the most powerful architectural concepts in software: indirection. https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar... Now curious as to which of these two first grasped the beauty of indirection in structures.