I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages
It was originablly conceived as a simulation of a distributed system.
Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
The amazing part to me is that so many were trained and convinced to accept that adopting this simulation could make all programming easier or somehow "better". As if adding complexity would magically lead to simplification.
> Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
I believe that programs written in languages made for distributed systems are simpler and easier to maintain.
Also I believe that one of the major problems in modern computing is that most languages we use do not understand that even trivial programs require ‘communication’ and OS/hardware facilities that have behaviours of distributed systems such as latency, transient faults, etc.
Generally speaking, toy examples can always be made to look simple. In reality it often means the “hard part” was moved into the shadows, not actually solved.
Graphical programming like LabVIEW looks very appealing. The product demo practically sells itself. Sure, it fits well for a very narrow class of use cases. But even fairly simple things in a textual language quickly become an unwieldy mess. (Try factoring an integer in it…)
There are formal models for distributed systems often solve the “easy” problems that didn’t need solving while making various practical concerns harder/impossible such as timeouts or node failure.
AFAIU, Simula focused more on types and inheritance and less on late-binding, in particular not of "all things".
Alan Kay's distaste for (static) types is just his opinion and an original contribution of IMO rather dubious value.
After the dust has settled, it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces.
There was a Soviet philosopher, Evald Ilyenkov, whose books taught me about a "minimal working model". I'll explain it in my own words.
People do not think with words: people think with things. Words serve merely as pointers to things. Some things are easy to point at; Ilyenkov talks about a cow. Some things are much harder to point at; Ilyenkov, being a Marxist, wanted to point to private property, we need to point to an object. Usually we try to talk about them using definitions, that is some sequences of words that are supposed to describe a thing. Such discussions are notoriously unproductive. The reason is that words are not really good as pointers: we have much more things than we have words and we have to reuse the same words to point to different things in different contexts. Yet in a phrase words look same so we tend to conflate these different things. As a result we get lost and go around in circles.
So instead of definitions Ilyenkov talks about a notion. Notion is something that reliably points to a thing that is hard to point at. It does not have to be an abstract thing: for example, we cannot point to radio. We can point to a household radio apparat but it has way too many parts completely unrelated to radio as a principle. So instead we build a minimal radio that has like three or four parts yet is capable of emitting or receiving radio waves.
We can do the same with abstract things too using the same approach. Let's build a minimal working model of a thing. "Working" so that the model indeed has the quality we are after; and "minimal" so that if we lose a single part, the quality is gone. Since the thing is abstract the model will also be abstract, that is it will be a sequence of words too, very much like a definition, but not quite.
(The same principle is widely used in parables: they describe some situation and thus try to guide your attention to certain qualities of it, hoping to trigger understanding. Sometimes it is hard to even name the thing they are pointing at, yet their pointing power is palpable. I myself often think about the parable about seven blind people and an elephant. You see I'm not naming the thing it points at: I don't have a good name for it.)
So let's go back to object oriented programming. What would be a minimal working thing that we can reliably call an object?
Here is what cannot be there. First, there must be no inheritance. If inheritance were required, then the first thing we build wouldn't be an object as it would have nothing to inherit from. Only the second thing would be an object and only because it inherited from the first. But this does not seem right. Second, there must be no polymorphism on the same grounds.
But at the same time if we do this:
class Aaaa
method bbbb():
...
then it is too minimal. It is hard to say how it is different from a function. It is not an object at all. Yet; there is a missing part that would turn this into a true object, but what the part is could be somewhat surprising.
side note, when first transistor-based portable radios showed up (as opposed to large lamp-based stationary devices), they were called "transistor". you would take not your portable radio with you, it was your transistor.
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages
It was originablly conceived as a simulation of a distributed system.
Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
The amazing part to me is that so many were trained and convinced to accept that adopting this simulation could make all programming easier or somehow "better". As if adding complexity would magically lead to simplification.
> Distributed systems can be useful but does anyone really believe that they are simpler or easier to develop and maintain?
I believe that programs written in languages made for distributed systems are simpler and easier to maintain.
Also I believe that one of the major problems in modern computing is that most languages we use do not understand that even trivial programs require ‘communication’ and OS/hardware facilities that have behaviours of distributed systems such as latency, transient faults, etc.
Generally speaking, toy examples can always be made to look simple. In reality it often means the “hard part” was moved into the shadows, not actually solved.
Graphical programming like LabVIEW looks very appealing. The product demo practically sells itself. Sure, it fits well for a very narrow class of use cases. But even fairly simple things in a textual language quickly become an unwieldy mess. (Try factoring an integer in it…)
There are formal models for distributed systems often solve the “easy” problems that didn’t need solving while making various practical concerns harder/impossible such as timeouts or node failure.
That's the Smalltalk school of OOP. There is also the Simula school. It is kind of unfortunate that they use the same name.
> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
How does Simula differ here?
AFAIU, Simula focused more on types and inheritance and less on late-binding, in particular not of "all things".
Alan Kay's distaste for (static) types is just his opinion and an original contribution of IMO rather dubious value.
After the dust has settled, it seems like the most valuable parts of OOP are private data, convenience (no need to repeat the class name in a method call), good fit for some domains, and interfaces.
private data, convenience
Which can be easily achieved without OOP.
In fact, to a certain point of view, OOP is a way to have modules bind to variables, and being extensible.
That upfront convenience here leads to a long tail of job security when it inevitably goes spaghetti. Win-win!
There was a Soviet philosopher, Evald Ilyenkov, whose books taught me about a "minimal working model". I'll explain it in my own words.
People do not think with words: people think with things. Words serve merely as pointers to things. Some things are easy to point at; Ilyenkov talks about a cow. Some things are much harder to point at; Ilyenkov, being a Marxist, wanted to point to private property, we need to point to an object. Usually we try to talk about them using definitions, that is some sequences of words that are supposed to describe a thing. Such discussions are notoriously unproductive. The reason is that words are not really good as pointers: we have much more things than we have words and we have to reuse the same words to point to different things in different contexts. Yet in a phrase words look same so we tend to conflate these different things. As a result we get lost and go around in circles.
So instead of definitions Ilyenkov talks about a notion. Notion is something that reliably points to a thing that is hard to point at. It does not have to be an abstract thing: for example, we cannot point to radio. We can point to a household radio apparat but it has way too many parts completely unrelated to radio as a principle. So instead we build a minimal radio that has like three or four parts yet is capable of emitting or receiving radio waves.
We can do the same with abstract things too using the same approach. Let's build a minimal working model of a thing. "Working" so that the model indeed has the quality we are after; and "minimal" so that if we lose a single part, the quality is gone. Since the thing is abstract the model will also be abstract, that is it will be a sequence of words too, very much like a definition, but not quite.
(The same principle is widely used in parables: they describe some situation and thus try to guide your attention to certain qualities of it, hoping to trigger understanding. Sometimes it is hard to even name the thing they are pointing at, yet their pointing power is palpable. I myself often think about the parable about seven blind people and an elephant. You see I'm not naming the thing it points at: I don't have a good name for it.)
So let's go back to object oriented programming. What would be a minimal working thing that we can reliably call an object?
Here is what cannot be there. First, there must be no inheritance. If inheritance were required, then the first thing we build wouldn't be an object as it would have nothing to inherit from. Only the second thing would be an object and only because it inherited from the first. But this does not seem right. Second, there must be no polymorphism on the same grounds.
But at the same time if we do this:
then it is too minimal. It is hard to say how it is different from a function. It is not an object at all. Yet; there is a missing part that would turn this into a true object, but what the part is could be somewhat surprising.don't say "apparat" when you can say "device".
side note, when first transistor-based portable radios showed up (as opposed to large lamp-based stationary devices), they were called "transistor". you would take not your portable radio with you, it was your transistor.