6 ms·

There are so many models based on the ideas of Kay. But I got the feeling that the actor model (Carl Hewitt) is closest to what Kay meant. Am I right?

by thdrdt 7y ago

jghn 7y ago
I can't find the quote online so this could easily be apocrypha or something I made up in my head, but I could have sworn Alan Kay has said as much along the way.
- anaphor 7y ago
  There's a quote from Joe Armstrong saying something like that > 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). https://stackoverflow.com/a/11809324/903589 https://stackoverflow.com/a/11809324/903589
  - trevyn 7y ago
    >If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money. Oof.
mathgladiator 7y ago
I think so, I'm accidentally building an actor centric programming language and it is a magical way of building stuff.
- bsaul 7y ago
  how do you handle persistence ? i’m trying to design a system at the moment and i feel like actors are great until you have to deal with persisting state to a database ( at which point the idea of having millions of independant process each hitting your database to save and load their state look like a disaster) edit : i misread your post, thought you were designing a system, not a PL... maybe you can still answer my question ?
  - pmontra 7y ago
    You should check how Erlang / Elixir database drivers handle that. In my experience with Elixir there are never many processes that have a state to save in a database. Eventually it's the same load no matter if the implementation is actor based or object oriented.
    - bsaul 7y ago
      but then how do you deal with transactionnal behaviors ?
      - pmontra 7y ago
        Check Elixir's Ecto module https://hexdocs.pm/ecto/Ecto.html https://hexdocs.pm/ecto/Ecto.html The general idea is to build the transaction in a pipeline of function calls. Each function gets the old definition of the transaction as an argument and returns a new one. Eventually the call at the end of the pipeline executes the statements in the definition, wrapping them in a transaction. If the question is how to deal with 100 or 100 k concurrent transactions, the answer again is in the same way a cluster of servers running programs written in any other language do. Eventually SQL is SQL.
  - verttii 7y ago
    That's not how you would persist to the database. Processes (Erlang VM threads) have mailboxes that process messages (like records to be saved to db) in a queue. Everything is built around message passing, each process just handles its own narrow job.
  - mathgladiator 7y ago
    I'm building my own database-like thing
  - ProfHewitt 7y ago
    Actors should be inherently persistent unless no longer reachable.
- rs23296008n1 7y ago
  I understand the accidental aspect. I've accidentally now written a spreadsheet while replacing a set of Makefiles with a more readable dependency graph of files. Now I'm adding a graphing component...
- ProfHewitt 7y ago
  Actors keep getting rediscovered because they are universal abstraction for digital computation.
  - DonHopkins 7y ago
    My nightmare scenario is that Larry Ellison rediscovers the Oracle Turing Machine, and copyrights its API. https://en.wikipedia.org/wiki/Oracle_machine https://en.wikipedia.org/wiki/Oracle_machine https://arstechnica.com/tech-policy/2019/11/supreme-court-will-review-high-stakes-google-v-oracle-ruling/ https://arstechnica.com/tech-policy/2019/11/supreme-court-wi... (In the cover photo of that article, it looks like people have been urinating on the Oracle logo!)
  - mathgladiator 7y ago
    I believe it, and I think we are in this stage of figuring out which model to represent it make the most sense in a broader scope.
pgt 7y ago
Yes. Erlang probably bears out the actor model best, although there are many library implementations in various languages.
- dnautics 7y ago
  Yes and no. Carl hewit will tell you that erlang's actor model is not pure (and to be sure a process doesn't have to be much of an actor - like Elixir's Task module). But I think that impurity is one of the strengths of the BEAM. So I would qualify 'best' to meant "easiest system that 95% looks like actors that you can quickly get up and running and doing useful things and or play around with"
  - anaphor 7y ago
    E (http://erights.org/ http://erights.org/), Monte (https://www.monte-language.org/ https://www.monte-language.org/), and Pony (https://www.ponylang.io/ https://www.ponylang.io/) are probably the most faithful actor-model languages I know of.
    - ProfHewitt 7y ago
      Above are important contributions, but they don't provide an adequate foundation for Actor massive concurrency.
      - dualogy 7y ago
        Any others around today that do?
        ProfHewitt 7y ago
        The Actor Model has been used in many important large applications [Bernstein, Bykov, Geller, Kliot, and Thelin 2014; Bonér and Reisz 2017, Cesarini 2019] and has become the foundation for current computing. Satisfactory implementation for Reusable Scalable Intelligent Systems with millions of Actor cores for quadrillions of Actor are under development, but not yet publicly available.
goofballlogic 7y ago
That had been my conclusions over the years. Erlang (or Elixir) are ironically one of the nicest environments for OO code these days (given they are usually categorized as "functional")
nailer 7y ago
The YC ideation talk with Alan Kay has a small rant from Alan about what he meant with Objects, and how that isn't what objects are used for now. What he described sounds exactly like the actor model.
madhadron 7y ago
He explicitly credited the actor model as one of the major influences on Smalltalk and OOP. The distinction as far as I have been able to tease it out is that in the actor model there is a distinction in kind between actors and values passed among actors. In OOP, there is no distinction in kind, that is, imagine you have an actor-like thing that sends you a reference to something, but that something is going to be of the same category of actor-like thing.
- abecedarius 7y ago
  Hewitt created actors after hearing an early Smalltalk talk by Kay at MIT, as I recall it. That wasn't the only influence (capabilities were a big one, for instance) and I'd be surprised if there wasn't reciprocal influence, though. In Hewitt's actor model, messages are also (immutable) actors. At least in the early version I read about.
  - ProfHewitt 7y ago
    Actors were developed to unify and overcome limitations of previous important contributions including lambda calculus [Church 1932] (first-class procedures), Petri nets [Petri 1962] (true concurrency), semaphores [Dijkstra 1962-1963], packet switching [Baran 1964] (concurrent communication between computers using fixed size packets), capabilities [Dennis and van Horn 1966] (pointer security), Simula [Dahl and Nygaard 1967] (class hierarchy), and SmallTalk-72 [Goldberg and Kay 1976] (bit-mapped computer graphics and browser, the precursor of modern programming Integrated Development Environments). The lambda calculus could not express concurrency with the consequence that lambda calculus programs can be thousands of times slower than Actors. A Petri net cannot dynamically expand and has the limitation that tokens can miraculously disappear from different places, which is inefficient to implement. Capabilities have the limitation that pointers must be manipulated using indexes into capability lists thereby making programming awkward. Simula did not implement concurrency and did not have messages. SmallTalk-72 used a byte stream of program tokens thereby making it awkward for concurrency. See the following for more information: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003

There are so many models based on the ideas of Kay. But I got the feeling that the actor model (Carl Hewitt) is closest to what Kay meant. Am I right?

by thdrdt 7y ago

There are so many models based on the ideas of Kay. But I got the feeling that the actor model (Carl Hewitt) is closest to what Kay meant. Am I right?

jghn 7y ago

I can't find the quote online so this could easily be apocrypha or something I made up in my head, but I could have sworn Alan Kay has said as much along the way.

anaphor 7y ago
There's a quote from Joe Armstrong saying something like that > 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). https://stackoverflow.com/a/11809324/903589 https://stackoverflow.com/a/11809324/903589
- trevyn 7y ago
  >If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money. Oof.

mathgladiator 7y ago

I think so, I'm accidentally building an actor centric programming language and it is a magical way of building stuff.

bsaul 7y ago
how do you handle persistence ? i’m trying to design a system at the moment and i feel like actors are great until you have to deal with persisting state to a database ( at which point the idea of having millions of independant process each hitting your database to save and load their state look like a disaster) edit : i misread your post, thought you were designing a system, not a PL... maybe you can still answer my question ?
- pmontra 7y ago
  You should check how Erlang / Elixir database drivers handle that. In my experience with Elixir there are never many processes that have a state to save in a database. Eventually it's the same load no matter if the implementation is actor based or object oriented.
  - bsaul 7y ago
    but then how do you deal with transactionnal behaviors ?
    - pmontra 7y ago
      Check Elixir's Ecto module https://hexdocs.pm/ecto/Ecto.html https://hexdocs.pm/ecto/Ecto.html The general idea is to build the transaction in a pipeline of function calls. Each function gets the old definition of the transaction as an argument and returns a new one. Eventually the call at the end of the pipeline executes the statements in the definition, wrapping them in a transaction. If the question is how to deal with 100 or 100 k concurrent transactions, the answer again is in the same way a cluster of servers running programs written in any other language do. Eventually SQL is SQL.
- verttii 7y ago
  That's not how you would persist to the database. Processes (Erlang VM threads) have mailboxes that process messages (like records to be saved to db) in a queue. Everything is built around message passing, each process just handles its own narrow job.
- mathgladiator 7y ago
  I'm building my own database-like thing
- ProfHewitt 7y ago
  Actors should be inherently persistent unless no longer reachable.
rs23296008n1 7y ago
I understand the accidental aspect. I've accidentally now written a spreadsheet while replacing a set of Makefiles with a more readable dependency graph of files. Now I'm adding a graphing component...
ProfHewitt 7y ago
Actors keep getting rediscovered because they are universal abstraction for digital computation.
- DonHopkins 7y ago
  My nightmare scenario is that Larry Ellison rediscovers the Oracle Turing Machine, and copyrights its API. https://en.wikipedia.org/wiki/Oracle_machine https://en.wikipedia.org/wiki/Oracle_machine https://arstechnica.com/tech-policy/2019/11/supreme-court-will-review-high-stakes-google-v-oracle-ruling/ https://arstechnica.com/tech-policy/2019/11/supreme-court-wi... (In the cover photo of that article, it looks like people have been urinating on the Oracle logo!)
- mathgladiator 7y ago
  I believe it, and I think we are in this stage of figuring out which model to represent it make the most sense in a broader scope.

pgt 7y ago

Yes. Erlang probably bears out the actor model best, although there are many library implementations in various languages.

dnautics 7y ago
Yes and no. Carl hewit will tell you that erlang's actor model is not pure (and to be sure a process doesn't have to be much of an actor - like Elixir's Task module). But I think that impurity is one of the strengths of the BEAM. So I would qualify 'best' to meant "easiest system that 95% looks like actors that you can quickly get up and running and doing useful things and or play around with"
- anaphor 7y ago
  E (http://erights.org/ http://erights.org/), Monte (https://www.monte-language.org/ https://www.monte-language.org/), and Pony (https://www.ponylang.io/ https://www.ponylang.io/) are probably the most faithful actor-model languages I know of.
  - ProfHewitt 7y ago
    Above are important contributions, but they don't provide an adequate foundation for Actor massive concurrency.
    - dualogy 7y ago
      Any others around today that do?
      - ProfHewitt 7y ago
        The Actor Model has been used in many important large applications [Bernstein, Bykov, Geller, Kliot, and Thelin 2014; Bonér and Reisz 2017, Cesarini 2019] and has become the foundation for current computing. Satisfactory implementation for Reusable Scalable Intelligent Systems with millions of Actor cores for quadrillions of Actor are under development, but not yet publicly available.

goofballlogic 7y ago

That had been my conclusions over the years. Erlang (or Elixir) are ironically one of the nicest environments for OO code these days (given they are usually categorized as "functional")

nailer 7y ago

The YC ideation talk with Alan Kay has a small rant from Alan about what he meant with Objects, and how that isn't what objects are used for now. What he described sounds exactly like the actor model.

madhadron 7y ago

He explicitly credited the actor model as one of the major influences on Smalltalk and OOP. The distinction as far as I have been able to tease it out is that in the actor model there is a distinction in kind between actors and values passed among actors. In OOP, there is no distinction in kind, that is, imagine you have an actor-like thing that sends you a reference to something, but that something is going to be of the same category of actor-like thing.

abecedarius 7y ago
Hewitt created actors after hearing an early Smalltalk talk by Kay at MIT, as I recall it. That wasn't the only influence (capabilities were a big one, for instance) and I'd be surprised if there wasn't reciprocal influence, though. In Hewitt's actor model, messages are also (immutable) actors. At least in the early version I read about.
- ProfHewitt 7y ago
  Actors were developed to unify and overcome limitations of previous important contributions including lambda calculus [Church 1932] (first-class procedures), Petri nets [Petri 1962] (true concurrency), semaphores [Dijkstra 1962-1963], packet switching [Baran 1964] (concurrent communication between computers using fixed size packets), capabilities [Dennis and van Horn 1966] (pointer security), Simula [Dahl and Nygaard 1967] (class hierarchy), and SmallTalk-72 [Goldberg and Kay 1976] (bit-mapped computer graphics and browser, the precursor of modern programming Integrated Development Environments). The lambda calculus could not express concurrency with the consequence that lambda calculus programs can be thousands of times slower than Actors. A Petri net cannot dynamically expand and has the limitation that tokens can miraculously disappear from different places, which is inefficient to implement. Capabilities have the limitation that pointers must be manipulated using indexes into capability lists thereby making programming awkward. Simula did not implement concurrency and did not have messages. SmallTalk-72 used a byte stream of program tokens thereby making it awkward for concurrency. See the following for more information: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003