5 ms·

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

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

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