Alan Kay and OO Programming

For example, look at class attributes and methods. I'm not sure they're needed but in a language like Java the semantics often leads to wildly different programming styles within the same code base. And it's hard to enforce consistent styles using conventions.

That said, I've seen/read Kay asked directly, on more than one occasion to elaborate on his notion of a real OOP language implementation and his answers are always to coy and slippery for my taste.

If you are actually looking to have some input from people who prefer statically typed languages about their reasons, you might want to write your comment in a way that does not presuppose that these people are obviously wrong (and, apparently, unwise).

Cells (co-)evolved for billions of years, they were not "designed" to accomplish certain tasks. Just survival and reproduction. And still, even with those billion of years, we still have cancer (as in bug in the reproduction process).

We design software. We evolve software. Software doesn't build itself, or decide for itself what's the best way to accomplish some task. We maintain software, we need guarantees, as much as we can get.

Dynamic languages let you think a problem you haven't thought of at design time will somehow solve itself magically at runtime, using components designed weeks before, with knowledge of that time.

It just doesn't work. It's an ideal vision that explodes as soon as your software gets any kind of commercial success and longevity, and you need to maintain it, and evolve it.

I think that's part of the trick, actually. When every component of a system behaves in similar ways, it's easier to extract that behavior into re-usable patterns.

Rather than each component worrying about handling failure and micromanagement, that job is delegated to an another component, a supervisor or orchestrator. Supervision trees, automatic service discovery, and elastic resource managers all come to mind.

What payment systems don't send messages to communicate with the credit card company, or the eCheck service, or Venmo/PayPal/Apple pay? Websites and native apps alike have spinning graphics and loading bars, messages that say "please don't refresh the page while we do this". These systems are fundamentally asynchronous to begin with. By uniformly applying the practices you get consistency, in exchange for a higher low-bar of complexity (which you're likely to exceed anyway).

Try to think about the following pieces:

1. A bee dies, the hive won't explode. Millions of cells die every minute within you.

In Erlang, usually, processes (object) are mostly organized as a bureaucratic structure, which has supervisors letting other objects doing the actual job. If someone dies or fails, the supervisor could just kill and replace them. This really looks like biological systems or human society. Not in a world that the boss let someone do some work, then the boss and the worker along with a whole world explodes if the worker fails (99% of OOP languages exception handling are not OOPish at all, it's totally imperative instead of modeling the relation between objects).

These correspond to the biological metaphor in the talk from Alan Kay in OP's article.

2. You can find and talk to someone alive if you know his address, email or phone number.

Java has object reference but it's not transparent to other systems, there is always the 'outside world' concept in this kind of reference or pointer system, similar to ST monad in Haskell. For a normalized database, there are transparent addresses for entity records, but they are dead and cannot talk to anyone until every time you need it, you sort of revive then interact with it for a short period, then you kill it and take its guts back to the database.

In Erlang, you can register any process (object) with an address like {user,42}, any other object can talk to it if they know the address, even from other servers. Just like how URL works mentioned in Alan Kay's talk.

3. The world is concurrent.

You have approximately a thousand audiences in a room. In order to count them, you let them all stand up. You tell everyone needs to get a number '1' in their mind. Then everyone finds another person, add their '1's, one person sits down, another person remains to stand, takes the former guy's number, then repeat the process. The last person stands has the count.

Usually, you only need to count very few times to get the answer. And this is what computer science is about. The problem is, that's not the way most computer program works. Because for most programs, even if you modeled 1000 people in Java, there's still only one person doing one thing at a time. Everyone runs on a monolithic thread. If you call libraries, you are giving them the most important thing you have -- the thread. And they don't promise they will return it to you.

Contrastly, in Erlang, every process (object) must have its own resource, no one can stop other people from doing things, no one can use up all the resources. The real world is a concurrent world where everyone is an isolated individual who can do things at the same time.