[yellowapple]

Imagine being a Smalltalker and still missing the underlying context of Joe's article - specifically, around the actor model (as used extensively in Erlang) being substantially closer to OOP as intended by e.g. Smalltalk than to the popularized inheritance-heavy brand of "OOP".

You can see this in the objections:

> Objection 1 - Data structure and functions should not be bound together

...and yet the usual way to store data in Erlang is to make it an argument of a function repeatedly and recursively calling itself.

> Objection 2 - Everything has to be an object.

...which is the case in Erlang/OTP, when you consider that everything is a process a.k.a. actor a.k.a. object. And just like with Smalltalk, these objects communicate via messages.

> Objection 3 - In an OOPL data type definitions are spread out all over the place.

...as they are in Erlang, because (barring some bolted-on approaches like records) data type definitions exist entirely as patterns to be matched.

> Objection 4 - Objects have private state.

...as do Erlang's processes.

That is, while maybe Joe didn't pick up on it at the time (per comments on that article: https://news.ycombinator.com/item?id=26586829), it's clear that said article was more a complaint against OOP as popularly envisioned, with all its classes and inheritance and such - not against the notion of object orientation entirely, which Erlang happens to implement, even if it might've been by accident.

[zelphirkalt]

Joe himself once said on stage (it was a video with him and Kay on stage, not sure of the name), that Erlang is either the most OOP lang or the least. I think he meant, that it depends on what OOP you look at. If you look at Smalltalk and message passing, as Kay highlights as the prominent ideas, then it might be the most OOP (or somewhere close to), while it is a 180 from mainstream OOP, when we look at the actor system and how distributed systems work.

[js8]

There is a function/type duality that goes very deep into foundations of mathematics, but it's a conceptually different one than the one proposed in OOP. So I don't think interpreting all those similarities as being OOP is quite correct.

[nesarkvechnep]

A small nitpick, Erlang doesn't implement the Actor model. The similarity of Erlang's processes and the actors, defined by Carl Hewitt, is accidental as stated by Joe Armstrong multiple times.

Edit: Actors doesn't run concurrently.

[yellowapple]

> Edit: Actors doesn't run concurrently.

Why not? That's literally the whole point of the actor model; actors are definitionally units of concurrent computation. That's exactly why Hewitt based the actor model on how e.g. particles interact in physics - those interactions necessarily being concurrent.

That is:

> The similarity of Erlang's processes and the actors, defined by Carl Hewitt, is accidental as stated by Joe Armstrong multiple times.

Just because processes accidentally behave like actors doesn't mean they ain't actors.

[balefrost]

Actors doesn't run concurrently.

Is that an actual law, or is it just that some implementations of the pattern are deficient? My impression is that the actor model was originally envisioned as being applied to a machine with hundreds or thousands of processors.

[michaelcampbell]

Erlang allows BEAMs on multiple machines, and of course multiple schedulers on multiple cores.

I think it'd be harder to make them run serially than concurrently, and of negative benefit.

Unless OP is saying this is some "rule" of being an Hewitt "Actor" in which case I'd call that somewhat arbitrary and unnecessary.

[michaelcampbell]

This feels a bit like a distinction without a difference. If 2 people come up on the same idea without knowledge of the other, that doesn't necessarily make them different ideas.

[HeckFeck]

Exactly, if anything it lends validity to the idea. See how Leibniz and Newton thrashed it out over calculus.