alt Hacker NewsYes, 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.
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.