5 ms·

Towards the end: But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by

by pfraze 12y ago

Towards the end: But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages. Sic transit gloria mundi. Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?

lucio 12y ago
I understand this passage as a comment on philosophical approach. You can see the same interaction as a "Remote Procedure Call" or as "sending a message to an object".
- agumonkey 12y ago
  Kay also said later that (anything lost in translation is my fault) he thinks he misjudged the scale of an object, instead of being tiny packs of methods, they should be interfaces for larger "computing devices". Like tiny virtual machines that can live into and move from actual hardware, and computing through communication over any kind of channels (local, remote).
Joeri 12y ago
A remote procedure call blocks on the response, ensuring the system is only as strong as its weakest link. If every object communicates asynchronously with every other object, using messages instead of shared memory (hence avoiding locking issues), the design by necessity evolves in ways which becomes more robust and easy to scale. Synchronous RPC calls encourage unscalable and unreliable architectures.
- pfraze 12y ago
  This is a good answer, but it doesn't cover everything Kay is suggesting. If it did, then the topic would be sync vs async messaging.
- jcrites 12y ago
  All remote calls must have a timeout. The lack of timeouts in certain RPC implementations was an implementation weakness, not a conceptual one. [Edit: I've removed most of my original comment since it pertained to messaging between machines, rather than within an application.]
wellpast 12y ago
I wish you hadn't asked this question b/c it sent me on a wild goose chase, mainly as I tried to reconcile my understanding of OOP vs. Kay's version of it, of which I'm still unclear. I perused the [1] he mentions to try and get better insight. (My version is much more born out of my history w/ C++/Java.) Kay says, OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. I read this to simply mean encapsulation of state + dynamic typing. RPC as I understand it is making a method call from one process to another, which makes no claim on how state and/or data should be handled and modeled. So I'm with you. Is Kay just arguing here for a specific way of thinking and talking about computing? Or are there some more concrete/tangible computing rules implied by what he's saying? [1] Dataless Programming (http://www.rand.org/content/dam/rand/pubs/research_memoranda/2007/RM5290.pdf http://www.rand.org/content/dam/rand/pubs/research_memoranda...)
- abecedarius 12y ago
  The concrete rules I'd give you are in http://en.wikipedia.org/wiki/Object-capability_model http://en.wikipedia.org/wiki/Object-capability_model -- note that inabilities are important, not just abilities. I'm a great fan of the thesis that's the first reference, which also gets into distributing the model over the network. I couldn't say if Kay would agree.
ridiculous_fish 12y ago
A remote procedure call is analogous to an ordinary function call, extended to a remote machine. It is static, perhaps even specifying the code to be executed, and therefore limited. But objects can be understood as independent agents (Kay calls them "real computers"), where a message is a request for some behavior. How the object is to implement that behavior is not specified in the message. Kay gives the example of the Internet itself. A GET request for a URI used to be understood as an RPC: download the file at this path. But today GET requests are routinely abstracted. There is no literal directory /r/programming on reddit. Instead path components are better understood as parameters, i.e. arguments in a message send! And this lets them do anything they want, be implemented in any manner at all. Unfortunately, this is one directional. Your browser makes an abstract request, but the server replies with literal code (e.g. JavaScript) that it wants executed on its behalf. The browser is sending messages to the server, but the server is making RPC calls to your browser. This gives some insight into the relative stagnation of the client-side, compared to the explosion of server-side. Kay wrote that, if you communicate via messages, then "each object could be implemented using the programming language most appropriate for its intrinsic nature." We have that on the server, but are a million miles away from that with clients.
- tedunangst 12y ago
  CSS (or more generally the dream of content and presentation separated HTML) might be considered message passing since the browser usually has some freedom with regards to on screen layout (implementation), although in practice many sites specify the message so precisely that only one implementation is possible.
DenisM 12y ago
That might be not what Alan Kay meant, but here's one description of fundamental problems with RPC: [1] [...] the fundamental problem is that RPC tries to make a distributed invocation look like a local one. This can't work because the failure modes in distributed systems are quite different from those in local systems, so you find yourself having to introduce more and more infrastructure that tries to hide all the hard details and problems that lurk beneath. That's how we got Apollo NCS and Sun RPC and DCE and CORBA and DSOM and DCOM and EJB and SOAP and JAX-RPC, to name a few off the top of my head, each better than what came before in some ways but worse in other ways, especially footprint and complexity. But it's all for naught because no amount of infrastructure can ever hide those problems of distribution. Network partitions are real, timeouts are real, remote host and service crashes are real, the need for piecemeal system upgrade and handling version differences between systems is real, etc. [...] [1] http://erlang.org/pipermail/erlang-questions/2008-May/035209.html http://erlang.org/pipermail/erlang-questions/2008-May/035209...
noblethrasher 12y ago
In a Smalltalk-style message passing system, each object has its own little parser. When you send it a message, the object will parse and interpret it however it wishes. Essentially, you send the object a sequence of tokens, it parses the tokens and generates some executable code that it then invokes. In C# (or Java), it would look something like this: interface Message : IEnumerable<Token> { } public class Foo { public void Consider(Object sender, Message msg) { //possibly validate sender... Executable result = this.Parse(msg); if(result.IsValid) sender.Consider(result.Execute(this)); else sender.Consider(new MethodMissing()); } private Executable Parse(msg) { //the ability to parse the message depends on the state of this object } } The basic idea is that the object is always in control of what it does. Methods are extremely late-bound because the code for the method may not even exist until the object first creates it in response to a received message. But, the big idea is that an object is just a little computer, and in a computer system, a computer is the smallest thing that you want to recapitulate.
- pdubroy 12y ago
  Sounds more like you're describing Smalltalk 72 (http://worrydream.com/EarlyHistoryOfSmalltalk/#p12 http://worrydream.com/EarlyHistoryOfSmalltalk/#p12) than Smalltalk 80. I've written a fair bit of Smalltalk code, and I can't remember seeing something like what you're describing here. It would certainly be possible, but I don't think it's an accurate description of how most Smalltalk code works.

by pfraze 12y ago

lucio 12y ago

I understand this passage as a comment on philosophical approach. You can see the same interaction as a "Remote Procedure Call" or as "sending a message to an object".

agumonkey 12y ago
Kay also said later that (anything lost in translation is my fault) he thinks he misjudged the scale of an object, instead of being tiny packs of methods, they should be interfaces for larger "computing devices". Like tiny virtual machines that can live into and move from actual hardware, and computing through communication over any kind of channels (local, remote).

Joeri 12y ago

A remote procedure call blocks on the response, ensuring the system is only as strong as its weakest link. If every object communicates asynchronously with every other object, using messages instead of shared memory (hence avoiding locking issues), the design by necessity evolves in ways which becomes more robust and easy to scale. Synchronous RPC calls encourage unscalable and unreliable architectures.

pfraze 12y ago
This is a good answer, but it doesn't cover everything Kay is suggesting. If it did, then the topic would be sync vs async messaging.
jcrites 12y ago
All remote calls must have a timeout. The lack of timeouts in certain RPC implementations was an implementation weakness, not a conceptual one. [Edit: I've removed most of my original comment since it pertained to messaging between machines, rather than within an application.]

wellpast 12y ago

I wish you hadn't asked this question b/c it sent me on a wild goose chase, mainly as I tried to reconcile my understanding of OOP vs. Kay's version of it, of which I'm still unclear. I perused the [1] he mentions to try and get better insight. (My version is much more born out of my history w/ C++/Java.) Kay says, OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. I read this to simply mean encapsulation of state + dynamic typing. RPC as I understand it is making a method call from one process to another, which makes no claim on how state and/or data should be handled and modeled. So I'm with you. Is Kay just arguing here for a specific way of thinking and talking about computing? Or are there some more concrete/tangible computing rules implied by what he's saying? [1] Dataless Programming (http://www.rand.org/content/dam/rand/pubs/research_memoranda/2007/RM5290.pdf http://www.rand.org/content/dam/rand/pubs/research_memoranda...)

abecedarius 12y ago
The concrete rules I'd give you are in http://en.wikipedia.org/wiki/Object-capability_model http://en.wikipedia.org/wiki/Object-capability_model -- note that inabilities are important, not just abilities. I'm a great fan of the thesis that's the first reference, which also gets into distributing the model over the network. I couldn't say if Kay would agree.

ridiculous_fish 12y ago

A remote procedure call is analogous to an ordinary function call, extended to a remote machine. It is static, perhaps even specifying the code to be executed, and therefore limited. But objects can be understood as independent agents (Kay calls them "real computers"), where a message is a request for some behavior. How the object is to implement that behavior is not specified in the message. Kay gives the example of the Internet itself. A GET request for a URI used to be understood as an RPC: download the file at this path. But today GET requests are routinely abstracted. There is no literal directory /r/programming on reddit. Instead path components are better understood as parameters, i.e. arguments in a message send! And this lets them do anything they want, be implemented in any manner at all. Unfortunately, this is one directional. Your browser makes an abstract request, but the server replies with literal code (e.g. JavaScript) that it wants executed on its behalf. The browser is sending messages to the server, but the server is making RPC calls to your browser. This gives some insight into the relative stagnation of the client-side, compared to the explosion of server-side. Kay wrote that, if you communicate via messages, then "each object could be implemented using the programming language most appropriate for its intrinsic nature." We have that on the server, but are a million miles away from that with clients.

tedunangst 12y ago
CSS (or more generally the dream of content and presentation separated HTML) might be considered message passing since the browser usually has some freedom with regards to on screen layout (implementation), although in practice many sites specify the message so precisely that only one implementation is possible.

DenisM 12y ago

That might be not what Alan Kay meant, but here's one description of fundamental problems with RPC: [1] [...] the fundamental problem is that RPC tries to make a distributed invocation look like a local one. This can't work because the failure modes in distributed systems are quite different from those in local systems, so you find yourself having to introduce more and more infrastructure that tries to hide all the hard details and problems that lurk beneath. That's how we got Apollo NCS and Sun RPC and DCE and CORBA and DSOM and DCOM and EJB and SOAP and JAX-RPC, to name a few off the top of my head, each better than what came before in some ways but worse in other ways, especially footprint and complexity. But it's all for naught because no amount of infrastructure can ever hide those problems of distribution. Network partitions are real, timeouts are real, remote host and service crashes are real, the need for piecemeal system upgrade and handling version differences between systems is real, etc. [...] [1] http://erlang.org/pipermail/erlang-questions/2008-May/035209.html http://erlang.org/pipermail/erlang-questions/2008-May/035209...

noblethrasher 12y ago

In a Smalltalk-style message passing system, each object has its own little parser. When you send it a message, the object will parse and interpret it however it wishes. Essentially, you send the object a sequence of tokens, it parses the tokens and generates some executable code that it then invokes. In C# (or Java), it would look something like this: interface Message : IEnumerable<Token> { } public class Foo { public void Consider(Object sender, Message msg) { //possibly validate sender... Executable result = this.Parse(msg); if(result.IsValid) sender.Consider(result.Execute(this)); else sender.Consider(new MethodMissing()); } private Executable Parse(msg) { //the ability to parse the message depends on the state of this object } } The basic idea is that the object is always in control of what it does. Methods are extremely late-bound because the code for the method may not even exist until the object first creates it in response to a received message. But, the big idea is that an object is just a little computer, and in a computer system, a computer is the smallest thing that you want to recapitulate.

pdubroy 12y ago
Sounds more like you're describing Smalltalk 72 (http://worrydream.com/EarlyHistoryOfSmalltalk/#p12 http://worrydream.com/EarlyHistoryOfSmalltalk/#p12) than Smalltalk 80. I've written a fair bit of Smalltalk code, and I can't remember seeing something like what you're describing here. It would certainly be possible, but I don't think it's an accurate description of how most Smalltalk code works.