> This metaobject post talks about the isomorphism between OOP and HTTP/REST/Servers
Emphatically: no, it does not. It makes the point that these are not isomorphic, at all.
Emphatically: no, it does not. It makes the point that these are not isomorphic, at all.
What I interpreted as what the author means by "what Alan Kay got wrong" is that Alan was just looking at the wrong isomorphism. The wrong aspect of essentially the same concept.
Outside of the OPs opinion though. I personally believe that there is an isomorphism between infrastructure and OOP.
> I disagree. He says ...
Hmmm..."he" (check my bio) might disagree with your assessment of what "he" said . ;-)
> the REST model could be better then message passing when scaled down
Yes. That's because it is not isomorphic to objects+messages (but built on top).
> then "he" says Alan Kay is right about messaging but that it's just one aspect of his storage combinator concept
Neither of those. It think he's right about generalising from "messages" to "interstitial/ma", which to me (and possibly only to me) means "connectors". That's the general concept (connectors define architectural styles, REST and objects/messages are specific architectural styles). Now of course "messaging" is closer than most other attempts.
> Alan was just looking at the wrong isomorphism.
Not really, he was scaling down the wrong thing, because the scaled up thing did not actually exist, so he had to imagine it, and when it did come into existence it did not match what he imagined it to be (and scaled down).
scaled up | scaled down
------------------------------------------------------------------
1. imagined computer network | objects and messages
2. real global network (WWW/REST) | In-process REST
scaled down | scaled back up
------------------------------------------------------------------------
1. objects and messages | CORBA/SOAP (Note on Distributed Computing)
2. In-process REST | WWW/REST
I think we're talking about different things so let me be clear about what I mean.
By isomorphism I mean a loose equivalence where the only thing that needs to be equal is structure. AN isomorphism between two different things is the preservation of Structure. In this specific case the structure I'm referring to is:
a system consisting of many (nodes that hold state and specific methods for communicating) that are talking with one another.
Anything that is isomorphic to the structure above is isomorphic to each other.
So using "=" to refer to an isomorphism what I was referring to is that:
JAVA = smalltalk = Servers communicating via REST = SERVERS communicating via SOAP/CORBA = objects and messages = OOP = nodes holding (state and methods) and communicating with one another.
So because all these things have an isomorphism they all have the same "Structural" problems as OOP that I described above and they are all basically different aspects of the same thing.
I think what you mean by "REST" worked and "CORBA" didn't is that CORBA/Soap didn't become popular while REST/WWW did, but if you look deeper there is no difference between the two concepts. CORBA/Soap is isomorphic to OOP which is isomorphic to REST. All these things are built off of a model where "nodes with state and methods communicate with one another" Maybe one system became popular because the semantics were easier to grasp or maybe there was a lot of extra fluff that needed to be implemented to get things to work. Either way I am not referring to this surface level difference. I am talking about a deeper OOP problem.
I am referring to an innate structural problem that comes with nodes that have both methods and state. The unionization of these two things leads to a design flaw.
Imagine one node with state that has a method that needs to be used in the context of another state. For example I have a node called SortedListOfCarsByPrice that contains a sort method. Later on, (possibly years later where design requirements change), in the design I realize I need an additional object called SortListOfPeopleByAge object. The design problem I hit here is that I want to reuse the sort method but it is tied state of SortedListOfCarsByPrice . The method modifies the state of the SortedListOfCarsByPrice object so I cannot pull it out and reuse it in another object that needs to modify the internal state of SortedListOfPeopleByAge. This is a trivial example of something that happens all the time with OOP and anything that is isomorphic to OOP.
Of course I could of had Parent Object with that method and had SortedListOfCarsByPrice and SortedListOfPeopleByAge be children of it, but my argument is saying that because the process of design makes it so that we may not know about this connection in the beginning. We usually come to realize this flaw later on in the game where it is essentially too late to change. OOP hits all kinds of design problems like this AS does microservices because the concepts are Isomorphic.
So to solve this problem Functions and state need to be subdivided into a different structure: The following definition is not isomorphic to OOP:
A system where there are two entities: Functions and Data. Functions only take input data and output new data. Data is an immutable unchanging piece of information that contains no methods.
If you understood what I said above maybe that will help my original thesis above be more clear as it certainly looks like I have failed to communicate my main point.
And, in those very same computer implementations, data cannot possibly contain methods. The compiler is going to treat them as ordinary function implementations, not any different from functions generated by the compilers of non-OO languages.
So I would love to see a mathematical proof of the isomorphisms you mentioned but, especially, a proof that your proposal is actually non-isomorphic to the other examples. I don't believe that holds true.
However when you don’t take a birds eye view Of everything a dichotomy exists between say OOP and say functional programming. We don’t talk about these two styles of programming as if they are the same thing just because an isomorphism exist at a different level. We view these two concepts from a different context and in that specific context OOP is different then FP hence the different naming. At the Turing machine level both styles coalesce into assembly language and at this level they are the same.
So at all levels above the Turing machine. If OOP is defined as nodes with states and methods communicating with one another.... Then microservices, rest and corba form an isomorphism. Because that’s what microservices are... nodes of servers with state and methods...
Surely this is different from a stateless pipeline of functions where data is put into the front of the pipe And a new value pops out of the other end of the pipe.
No mathematical proof can describe this dichotomy because essentially Turing completeness says everything is the same thing so I’m operating at a different level if you know what I mean. Maybe a smarter person has a way to illustrate this dichotomy formally but all I’m going for is you understanding what I’m talking about.
By no means I want to sound inquisitive, but, if it is different, how is it? Is one of these models (OOP and functional) a subset of the other? If so, do they represent levels in a given hierarchy? If not, do they even intersect? Are dissimilar properties complementary?
https://www.wikiwand.com/en/Turing_completeness
Procedural programming and functional programming occupy the same level in this sense. I know of no "theory" that describes the evident dichotomy between the two. Lambda calculus is different from a turing machine simply because it feels different. Just like there is no theory illustrating the difference between JAVA and elixir. The only theory available says that everything is the same if it's turing complete.
As i mentioned before however, there are issues with things that can actually exist in reality. I do not believe an actual lambda machine can be built in reality but in the theoretical world you can if you wanted to define something as "lambda complete" you could and have the lambda be the basis of things.
As for OOP and functional programming, again there is no formal description of the dichotomy.
In fact there is no formal description of OOP. OOP is not part of computability theory and to my knowledge not really studied by theorists. OOP is just a popular style that exists in the business world.
So in short the available academic knowledge implies that all of these isomorphisms occupy the same level. That is there is no hierarchy or no one has tried to map a hierarchy yet.
You might be right that there is a hierarchy. I would think lambda calculus sits at the apex simply because lambda calculus separates the concept of state and function while OOP and turing machines combine the two primitives (Object = (state * function)). However from other perspectives, there is no real world analog of a lambda calculus machine so from that perspective you could organize the hierarchy by putting OOP or the turing machine on top because it can exist in reality. But like how the number 1 is made out of three primitives that don't exist in reality: (-1 * i * i) I would say the smaller division of primitives is the more fundamental concept and therefore higher on the hierarchy.