[mwattsun]

Right, I understand where I wasn't clear. You're right, that idea has won and gone mainstream so I didn't think it was worth mentioning. I was emphasizing that I thought immutable data structures were inefficient and that it was the luxury of academics to abstract away stateful changes in the name of purity.

I've got a couple of other ideas that I need to do more research on (I'm watching Erik Meijer videos today)

1) Class objects with methods and data are like small programs, so I don't get why people go on and on about having data structures with functions as being superior to class objects, which are essentially data structures with associated functions.

2) Similarly, Joe Armstrong seems to hate object oriented programming but Erlang instances are essentially class objects, albeit running in their own process so they have more isolation

3) From reading Erik Meijer's Confessions of a Used Programming Language Salesman, I'm assuming that Async/Await that he help put in C# and Dart are his attempt to bring Haskell continuation monads to the imperative world

4) I'm assuming Clojure Atoms and Actors are like Haskell monads but don't know that. I watched Brian Beckman: Don't fear the Monad (https://www.youtube.com/watch?v=ZhuHCtR3xq8) but couldn't make heads or tails of it. Something about functions calling first order functions and pure first order effects with stateful second order effects, or something... That was a few years ago so I will give it another chance.

I'm probably wrong about these ideas but they're fun to think about and give me something to learn

[Zalastax]

My view on 2 is that you get into a quite different mindset when you program actors, compared to objects. For starters, since each actor is scheduled separately, it becomes routine to not assume too much about the internal state of the actor. So you won't see many getters + setters in Erlang, for example. You also need to structure your program to not communicate unnecessarily, since communication may fail and requires you to wait for the other actor to reply. This makes you to think about what state should belong to which actor. It is quite subtle and is best seen by experiencing it, but I think the programs turn out quite different, and in my view better. Actors are not perfect for everything but to me they are what object oriented programming should have been.

[mwattsun]

I realized additionally is that Armstrong has other complaints about OOP like inheritance. What I said above in that classes and functions are like a self-contained programs with structs and functions. I wasn't considering inheritance, but once you start inheriting it gets murky:

Joe Armstrong: Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle

But some of his other complaints don't feel as right to me:

http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

I do love the implementation of Erlang and the reliability. I think it would fun to try actors and see if it changes how I view software engineering. I bet it would.