[sdfsdfs34dfsdf]

That's quite the thing to bring up. Wonderful.

So you say an object is like a computation stretched over time and a function that same computation but compressed into a single invocation? Like an object is a computation whose execution is suspended between messages? I can see how that ties closures, co-routines, etc together. They are all machinery to preserve execution state across time.

Generally you could say computation is traversal through a space of states and in that frame objects expose the intermediate states, the guts so to speak, and functions hide them and only expose the in-out mapping.

I feel these are two poles of some deeper principle. Ah man, I'm not well-read enough to go further than this. I kind of worry why most developers are not deeply familiar with this material because these things will inform many foundational choices we make in system architecture and we'd definitely could use some better shared vocabulary and argumentative machinery than mere opinions and "that's how we always do it".

[Mikhail_Edoshin]

Yes, this is exactly what I'm saying. Objects, closures, co-routines and eventually state machines, which was the first concept, I think, all revolve around the same core thing.

We keep returning to it because this is the natural way to do computation using a machine, but we also try to escape because it is rather hard for a human. We like the functional form more: it looks sequential and goes nicely from start to end. With objects we quickly lose our way in a soup of small parts.

[sph]

This is known as the object lambda duality which Guy Steele wrote about. If you think hard enough, you reach this core idea that objects and closures are just yin and yang, inseparable.

https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

So why have objects when you have closures? I believe that by externalising the decision on how to behave when a method (selector) is called, into a concept like a vtable, you can apply greater levels of optimisations.

In other words, a closure is a object that encapsulates (keeps private) the list of function pointers it is able to respond to. This is not necessary, and Piumarta (linked by me elsewhere in this thread) shows you can reach this generalisation well within the OOP system, by making vtables themselves objects which respond to a lookup method that returns a function pointer.