4 ms·

So wasn't this part of the original dream for Smalltalk? Then this would seem to be coming full circle: Smalltalk, Objective C, Swift and back. I know some of y

So wasn't this part of the original dream for Smalltalk? Then this would seem to be coming full circle: Smalltalk, Objective C, Swift and back. I know some of you are Alan Kay fans so maybe you can comment on that aspect.

tytrdev 5y ago
Yes, but only a part. It’s not just about having something akin to actors for concurrency and execution. It’s also about having a dynamic system - one that can update its behavior not just by manual request, but automatically as the system is running. One way to think about this is propagators. I’m still learning myself, but a compelling example is lisp. With lisp you can write macros that essentially allow you to treat your code as a tree and arbitrarily modify that tree (aka arbitrarily write code). You can then compile that code while the system is running and execute it. It’s not just about macro expansion at startup or a single compile time step at the beginning of execution. The system can be designed with this in mind. It’s also about introspection, the ability to ask questions about the system at runtime as it evolves. Sussman and Kay both talk a lot about DNA and biology, and the ability for systems to dynamically expand, change, and repair themselves. When I think about this kind of stuff nowadays I picture something like lisp with an execution environment like the BEAM (so basically LFE) and an introspection system powered by a declarative constraint solving query language (something like Datalog-style RDF found in things like datalevin and it’s predecessors). I think that lends itself really well to these kinds of systems, including another point that Kay talks about pretty frequently. The ability for two systems (and in our cases two actors in one environment count) to negotiate with each other via some shared fundamental language to understand each other’s purpose. SOP style approaches seem like a compelling way to do that, but the main problem to me is identifying entities as globally unique as part of that negotiation process. Also don’t listen to me, I’m a monkey.
- ProfHewitt 5y ago
  Probably can't make much progress without a scientific foundation including the Actors Abstraction.
igouy 5y ago
There were a lot of researchy implementations: "Writing Concurrent Object-Oriented Programs using Smalltalk-80" http://www.wolczko.com/mushroom/compj.pdf http://www.wolczko.com/mushroom/compj.pdf "Actra = A Multitasking / Multiprocessing Smalltalk" https://dl.acm.org/doi/10.1145/67387.67409 https://dl.acm.org/doi/10.1145/67387.67409 Actra -- an industrial strength concurrent object-oriented programming system https://dl.acm.org/doi/10.1145/127070.127090 https://dl.acm.org/doi/10.1145/127070.127090
eyelidlessness 5y ago
Given the heritage I’d also say it’s good to recognize the Actor model in Erlang/OTP and the overlap that has with Smalltalk and everything that followed.
- ProfHewitt 5y ago
  The Actors Abstraction is foundational for computer science analogous to the Natural Numbers in classical mathematics.
mikro2nd 5y ago
Absolutely. I was watching Alan Kay's "Inventing the Future" talks recorded a few years ago, and this was a thing he referred to in passing. In recent month's, every time I run across the whole "OO is evil/dead/horrible" meme (esp. common here) it turns out to be someone talking whose experience of "OO programming" is limited to C++/Java and their relatives. If your only exposure to OO was those (and similar) languages, then, YES, OO is horrible and weak and full of leakiness in the abstractions. It's a bit like saying that coffee is horrible when all you've ever tasted is cheap-and-nasty instant made from acorns and floor sweepings. C++ and Java (I can't comment on C#, never having used it in anger) are the palest, anaemic shadow of OO programming. Rant done. This addition to Swift might cause me to look at it more closely. (I don't have any reason/desire to touch the Apple grow-tunnel (as opposed to ecosystems, which are natural and open.) My thoughts have also recently run along lines of "What if we made every message to an object as if it were always remote (in another address space)?" In other words, for decades we've been trying to make RPC calls look (to the programmer) as if they were "just like local calls" and with justifiable lack of success because remote really is more wrinkly than local. So what if, instead of trying to make "remote" look/behave/imitate "local" we went in the other direction and make all calls look like remote calls? It means we have to think about all the failure modes and partial-failure modes of remote calls all of the time. Only, for local address-space calls, they're going to be much more reliable in practise. Is it worth it? Can we bring down the cognitive overhead to an acceptable level? I'm interested to see whether this Swift effort/initiative approaches this idealised/simplified description.
- rackjack 5y ago
  Am I correct in thinking that this is similar to "Session Types"?
- rapsey 5y ago
  You are describing Erlang and it can not get simpler than that.
  - ProfHewitt 5y ago
    I fondly remember Joe Armstrong, who was a good friend. However, not having a mathematical foundation has been a severe limitation for Erlang. The Erlang community is trying to dig its way out with modifications and extensions. Still have a long way to go. Of course, no Actors framework is perfect. Many important implementations have been done Erlang. Also, significant Erlang projects are ongoing to good effect.

tytrdev 5y ago

Yes, but only a part. It’s not just about having something akin to actors for concurrency and execution. It’s also about having a dynamic system - one that can update its behavior not just by manual request, but automatically as the system is running. One way to think about this is propagators. I’m still learning myself, but a compelling example is lisp. With lisp you can write macros that essentially allow you to treat your code as a tree and arbitrarily modify that tree (aka arbitrarily write code). You can then compile that code while the system is running and execute it. It’s not just about macro expansion at startup or a single compile time step at the beginning of execution. The system can be designed with this in mind. It’s also about introspection, the ability to ask questions about the system at runtime as it evolves. Sussman and Kay both talk a lot about DNA and biology, and the ability for systems to dynamically expand, change, and repair themselves. When I think about this kind of stuff nowadays I picture something like lisp with an execution environment like the BEAM (so basically LFE) and an introspection system powered by a declarative constraint solving query language (something like Datalog-style RDF found in things like datalevin and it’s predecessors). I think that lends itself really well to these kinds of systems, including another point that Kay talks about pretty frequently. The ability for two systems (and in our cases two actors in one environment count) to negotiate with each other via some shared fundamental language to understand each other’s purpose. SOP style approaches seem like a compelling way to do that, but the main problem to me is identifying entities as globally unique as part of that negotiation process. Also don’t listen to me, I’m a monkey.

ProfHewitt 5y ago
Probably can't make much progress without a scientific foundation including the Actors Abstraction.

igouy 5y ago

There were a lot of researchy implementations: "Writing Concurrent Object-Oriented Programs using Smalltalk-80" http://www.wolczko.com/mushroom/compj.pdf http://www.wolczko.com/mushroom/compj.pdf "Actra = A Multitasking / Multiprocessing Smalltalk" https://dl.acm.org/doi/10.1145/67387.67409 https://dl.acm.org/doi/10.1145/67387.67409 Actra -- an industrial strength concurrent object-oriented programming system https://dl.acm.org/doi/10.1145/127070.127090 https://dl.acm.org/doi/10.1145/127070.127090

eyelidlessness 5y ago

Given the heritage I’d also say it’s good to recognize the Actor model in Erlang/OTP and the overlap that has with Smalltalk and everything that followed.

ProfHewitt 5y ago
The Actors Abstraction is foundational for computer science analogous to the Natural Numbers in classical mathematics.

mikro2nd 5y ago

Absolutely. I was watching Alan Kay's "Inventing the Future" talks recorded a few years ago, and this was a thing he referred to in passing. In recent month's, every time I run across the whole "OO is evil/dead/horrible" meme (esp. common here) it turns out to be someone talking whose experience of "OO programming" is limited to C++/Java and their relatives. If your only exposure to OO was those (and similar) languages, then, YES, OO is horrible and weak and full of leakiness in the abstractions. It's a bit like saying that coffee is horrible when all you've ever tasted is cheap-and-nasty instant made from acorns and floor sweepings. C++ and Java (I can't comment on C#, never having used it in anger) are the palest, anaemic shadow of OO programming. Rant done. This addition to Swift might cause me to look at it more closely. (I don't have any reason/desire to touch the Apple grow-tunnel (as opposed to ecosystems, which are natural and open.) My thoughts have also recently run along lines of "What if we made every message to an object as if it were always remote (in another address space)?" In other words, for decades we've been trying to make RPC calls look (to the programmer) as if they were "just like local calls" and with justifiable lack of success because remote really is more wrinkly than local. So what if, instead of trying to make "remote" look/behave/imitate "local" we went in the other direction and make all calls look like remote calls? It means we have to think about all the failure modes and partial-failure modes of remote calls all of the time. Only, for local address-space calls, they're going to be much more reliable in practise. Is it worth it? Can we bring down the cognitive overhead to an acceptable level? I'm interested to see whether this Swift effort/initiative approaches this idealised/simplified description.

rackjack 5y ago
Am I correct in thinking that this is similar to "Session Types"?
rapsey 5y ago
You are describing Erlang and it can not get simpler than that.
- ProfHewitt 5y ago
  I fondly remember Joe Armstrong, who was a good friend. However, not having a mathematical foundation has been a severe limitation for Erlang. The Erlang community is trying to dig its way out with modifications and extensions. Still have a long way to go. Of course, no Actors framework is perfect. Many important implementations have been done Erlang. Also, significant Erlang projects are ongoing to good effect.