ErlangAndSmalltalk

Is Erlang closer to Alan Kay's original vision of OOP than Smalltalk?

Sep 27, 2019 https://www.quora.com//Is-Erlang-closer-to-Alan-Kays-original-vision-of-OOP-than-Smalltalk/answer/Phil-Jones-He-Him

Only Alan Kay can tell you for sure. But I seem to remember him saying somewhere that Smalltalk-71 was more like Erlang but Smalltalk-72 moved in a slightly different direction, mainly because of the emphasis on the GUI environment.

Maybe I'm misremembering, but it would be quite interesting if this were the case. Actors seem cooler than Objects in the sense of all living in their separate threads. But Actors don't share state. And possibly shared state is something that makes handling, say, editable bitmaps and the other very stateful widgets of a GUI environment, tractable.

Quora Answer : Why does Smalltalk not become mainstream OS for cloud computing? Its message passing paradigm looks like totally native for scalability, going to modish Actors model.

May 27, 2018

Basically, it's about synchronous vs. async. message passing.

Cloud / internet scale needs async to cope with the lag of long distance communication. But Smalltalk is fundamentally about synchronous messages within a single process.

If Smalltalk gained an elegant and native actor or CSP type semantics and notation, with Erlanglike light-weight native threads then I think it could become a contender.

The tricky part is that Erlang thinks very specifically about data. No data gets shared between processes except copied and passed by value. All data is immutable and ephemeral. This makes it inefficient for handling large complex long-lived data-structures. But that's fine for the kinds of applications Erlang is meant for.

OTOH Smalltalk is heavily dependent on persistent stateful objects. That's what the entire system is made of.

If you want Erlanglike robustness and simplicity you need to adopt Erlang's approach to data.

But by the time you've reinvented Smalltalk's world in terms of ephemeral immutable datatypes, it's debatable how much of the spirit of Smalltalk is left. You've basically got Erlang with a more objecty syntax. In which case why not just go straight for Elixir?

Nevertheless I think it could be done. Add an Actor as an alternative top level Object class. Which always spawns new processes for each instance, shares no data, and only communicates by async messages. All arguments in messages to other Actors would be deep copied. I'd like to see Smalltalk tweaked anyway with the ability to mark some instance variables as immutable. To create a Let / Set distinction. Add some efficient immutable data structures.

Put this into a next-gen Smalltalk and you have something which might well be a useful elegant way to write cloud services.

I used to think that the monolithic image was another problem for Smalltalk on the server. But in the age of Docker and Kubernetes etc. that looks increasingly like Smalltalk being ahead of its time.