4 ms·

It's interesting that author is avoiding talking about the Actor Model which has an obvious overlap with the mainstream OOP in terms of stateful objects communi

by CmonDev 12y ago

It's interesting that author is avoiding talking about the Actor Model which has an obvious overlap with the mainstream OOP in terms of stateful objects communicating with messages yet is being embraced by functional developers (Akka, Erlang).

danieldk 12y ago
An actor in Erlang is not an object, but a (usually recursive) function where receive is called in each recursion. It's stateful in the sense that Haskell functions are stateful: you pass a new state as an argument to the next function.
- tormeh 12y ago
  Same same, but different.
- djur 12y ago
  Actors and objects are closely related. Erlang processes provide encapsulation, the indefinite recursion allows maintaining local state, and dynamic dispatch is provided directly by the programmer or by behaviors.
- rdtsc 12y ago
  > An actor in Erlang is not an object And function with closure and/or with a state passed through and it is an as good as an object. Heck, look at one of the most popular languages -- Python. Method calls look nice an explicit like def method(self,...). Others have self too (usually called "this"), but it appears there implicitly. At the memory level Erlang actors are even better objects because they actually enforce memory isolation. Which is in spirit with Alan Kay's original OO idea.
  - danieldk 12y ago
    Heck, look at one of the most popular languages -- Python. Method calls look nice an explicit like def method(self,...). Others have self too (usually called "this"), but it appears there implicitly. "Foolish pupil - objects are merely a poor man's closures." And visa versa. However, this line of reasoning definitely differs from what one nowadays considers an object-oriented language. Which was exactly what this article was about.
rdtsc 12y ago
Interestingly Erlang creators saw the problem and solved in a practical way a while back. It was funny in that they didn't go read academic literature, they hadn't even heard about the "actor model". They just realized that they needed to minimize large mutable states in concurrent programs. Variables are single assignment, data is immutable. One object (actor) crashing doesn't impact others. Then eventually later someone said "hey that's the actor model you are using". They also didn't set out to create a functional language explicitly. They didn't know about monads, applicative, functors etc. Another funny anectode, Joe Armstrong is quite fond of calling Erlang the only true OO language in its original sense. The idea of methods being messages sent between isolated and opaque objects. This isolation is really enforced at the heap level and methods are really messages being send to an actor's mailbox. If you listen to Alan Kay, he mostly agrees: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... --- OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. Cheers, Alan ---
- CmonDev 12y ago
  Very true, also Erlang is different from pure Actor Model AFAIK because it provides certain guarantees that messages will be ordered, unlike: http://en.wikipedia.org/wiki/Actor_model#No_requirement_on_order_of_message_arrival http://en.wikipedia.org/wiki/Actor_model#No_requirement_on_o...
- angersock 12y ago
  I've heard it put that Erlang was created to solve the issues of distributed system, and as a result, solved concurrency for free. I really like it because it feels like it was meant to do something other than pad out a thesis--it's probably the only functional language other than F# or LINQ to do that.

by CmonDev 12y ago

danieldk 12y ago

An actor in Erlang is not an object, but a (usually recursive) function where receive is called in each recursion. It's stateful in the sense that Haskell functions are stateful: you pass a new state as an argument to the next function.

tormeh 12y ago
Same same, but different.
djur 12y ago
Actors and objects are closely related. Erlang processes provide encapsulation, the indefinite recursion allows maintaining local state, and dynamic dispatch is provided directly by the programmer or by behaviors.
rdtsc 12y ago
> An actor in Erlang is not an object And function with closure and/or with a state passed through and it is an as good as an object. Heck, look at one of the most popular languages -- Python. Method calls look nice an explicit like def method(self,...). Others have self too (usually called "this"), but it appears there implicitly. At the memory level Erlang actors are even better objects because they actually enforce memory isolation. Which is in spirit with Alan Kay's original OO idea.
- danieldk 12y ago
  Heck, look at one of the most popular languages -- Python. Method calls look nice an explicit like def method(self,...). Others have self too (usually called "this"), but it appears there implicitly. "Foolish pupil - objects are merely a poor man's closures." And visa versa. However, this line of reasoning definitely differs from what one nowadays considers an object-oriented language. Which was exactly what this article was about.

rdtsc 12y ago

Interestingly Erlang creators saw the problem and solved in a practical way a while back. It was funny in that they didn't go read academic literature, they hadn't even heard about the "actor model". They just realized that they needed to minimize large mutable states in concurrent programs. Variables are single assignment, data is immutable. One object (actor) crashing doesn't impact others. Then eventually later someone said "hey that's the actor model you are using". They also didn't set out to create a functional language explicitly. They didn't know about monads, applicative, functors etc. Another funny anectode, Joe Armstrong is quite fond of calling Erlang the only true OO language in its original sense. The idea of methods being messages sent between isolated and opaque objects. This isolation is really enforced at the heap level and methods are really messages being send to an actor's mailbox. If you listen to Alan Kay, he mostly agrees: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... --- OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. Cheers, Alan ---

CmonDev 12y ago
Very true, also Erlang is different from pure Actor Model AFAIK because it provides certain guarantees that messages will be ordered, unlike: http://en.wikipedia.org/wiki/Actor_model#No_requirement_on_order_of_message_arrival http://en.wikipedia.org/wiki/Actor_model#No_requirement_on_o...
angersock 12y ago
I've heard it put that Erlang was created to solve the issues of distributed system, and as a result, solved concurrency for free. I really like it because it feels like it was meant to do something other than pad out a thesis--it's probably the only functional language other than F# or LINQ to do that.