As a present day Lazarus/Free Pascal programmer... I found this dive into history interesting. I had an almost allergic reaction to the idea of not type checking everything at compile time, but I do see how in some cases it can help if that is postponed.

What was REALLY interesting to me was the idea of objects as processes, and passing messages instead of function calls. The machine I'm using to type this has an 8 cores, and I can see that thousands are on the way eventually. Hanging on to programming models that only execute serially will become very time prohibitive in the near term future.

The idea of immutable variables always struck me as oxymoronic... but if an object is always resolved by id or name each time it is used, it resolves some rather nasty deadlocks, while allowing failure to be recovered from.

It seems obvious to me that I'm going to have to give up the ability to know exactly how variables are stored, in order to gain this flexibility. It seems like it will be worth the trade off, as compute cost declines, and communication costs remain relatively constant.

There is much in this to ponder, thanks for sharing.

> The idea of immutable variables always struck me as oxymoronic

It is, they're called constants.

That's a bad choice of name from one or more old languages that misused established mathematical terminology (e.g. C misuses void, constant and variable). An immutable variable (or in maths, just "variable') has a value that is unknown at build time but is constant at runtime. A constant has a known value at build time.

What nearly every language calls a variable today, is probably better described as a "reference" or "assignable", but sadly that ship has sailed and we'll forever be inconsistent with the math terminology for that one. Immutable variable is therefore a useful synonym for "proper variable".

Bad choice or no, the language is appropriate... Constants should remain constant at runtime. Variables should be allowed to vary. I don't see why people think immutable strings is a good idea, for example. How do you ever build a text editor, if the strings can't be edited?

Regarding your skeptism of immutable data structures, it's best to think of immutable data and data structures as copy-on-write instead of update-in-place. This is a technique that is currently very underused, for example most programming languages do not come with "persistent" copy-on-write collections.

Here is an example text editor built using immutable data structures in C++: https://github.com/arximboldi/ewig

Advantages are excellent support for concurrency (background save works while you edit) and trivial support for undo/redo.