4 ms·

I disagree. He says that the rest model could be better then message passing when scaled down, then he says Alan Kay is right about messaging but that it's just

I disagree. He says that the rest model could be better then message passing when scaled down, then he says Alan Kay is right about messaging but that it's just one aspect of his storage combinator concept. 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.

mpweiher 7y ago
>> ...no, it does not. ... > 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 And my evidence for (1) being wrong is that scaling objects and messages back up did not actually work. scaled down | scaled back up ------------------------------------------------------------------------ 1. objects and messages | CORBA/SOAP (Note on Distributed Computing) 2. In-process REST | WWW/REST Anyway, thanks for reading and thinking it through!
- crimsonalucard 7y ago
  Ok, did not realize you were the author, apologies. 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. This is what I consider to be the modern definition of OOP and is isomorphic to Alan Kays definition of message passing between objects(nodes) that hold state. 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. By splitting Objects into its constituent pieces suddenly no sort method is ever tied to the data of SortedListOfCarsByPrice. By it's very nature the sort method is tied to nothing and can be moved across the context of all sorts of data. I can use sort to sort lists of cars by price and People by age because sort is not tied to data. 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.

mpweiher 7y ago

>> ...no, it does not. ... > 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 And my evidence for (1) being wrong is that scaling objects and messages back up did not actually work. scaled down | scaled back up ------------------------------------------------------------------------ 1. objects and messages | CORBA/SOAP (Note on Distributed Computing) 2. In-process REST | WWW/REST Anyway, thanks for reading and thinking it through!

crimsonalucard 7y ago
Ok, did not realize you were the author, apologies. 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. This is what I consider to be the modern definition of OOP and is isomorphic to Alan Kays definition of message passing between objects(nodes) that hold state. 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. By splitting Objects into its constituent pieces suddenly no sort method is ever tied to the data of SortedListOfCarsByPrice. By it's very nature the sort method is tied to nothing and can be moved across the context of all sorts of data. I can use sort to sort lists of cars by price and People by age because sort is not tied to data. 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.