At the boundaries, applications are themselves objects, and the JSON you use to communicate with them are immutable messages. They, if we’re also talking (micro)services, are the closest thing to what Alan Kay envisioned as “objects”. (And similarly what exists in Erlang, if I’m not mistaken.)
Also, as a point:
While an object is data with behaviour, closures are behaviour with data. Such first-class values cross system boundaries with the same ease as objects do: Not very well.
Yes, well, state being bound up in a function would be a problem, but otherwise a pure stateless function is going to cross just fine. Assuming it executes in a limited context that has its dependencies. (Alternatively, you could transform said function into a single function of all its dependencies inlined.)
And, a function can include local data, as static information within itself. Of course, none of this is literally an object/closure with running state, but, if we wanted to get pedantic, we could totally send an image of a running process or module and spin it up on the other end, like communication via passing Lisp images, but that’s really stretching the imagination… or maybe an amusing thought exercise… At this point we’re reaching similar modeling of the biological world, and maybe Alan Kay, being a biologist, would find this amusing.
Assuming it executes in a limited context that has its dependencies.
If we’re going to assume the remote has the right dependencies, why not just assume that the remote has the stateless function as well and just send the data that parameterizes the function? That’s basically how RPC works today (and has worked for a long time). It doesn’t seem very useful to be able to marshal functions but only to remotes which have the dependencies pre-installed. It seems like we shouldn’t assume dependencies are installed and either do our normal RPC stuff or we come up with a scheme for marshaling the dependencies over the wire as well (perhaps with some caching so we’re not marshaling them to remotes that already have them).
Moreover, regardless of whether we’re sending dependencies or not, sending stateless functions isn’t particularly easy in a natively compiled language because you’re assuming the remote has the same architecture and a compatible kernel (or libc in many cases). So you need to either need to enforce that invariant or else you need to keep a platform agnostic version of the function (e.g., source code or VM bytecode) and ship that which means some kind of compiler/runtime on the remote.
All of this seems to support the “not very well” characterization of marshaling closures and objects.
Of course the inventors of object-orientation would likely take issue with your deduction that microservices, immutable messages and Erlang best constitute their concepts (it wasn’t Alan Kay). This is taking the magical “it’s all about messaging” to an absurd extreme.
are the closest thing to what Alan Kay envisioned as “objects”
This implication that Alan Kay somehow invented objects is incorrect, yet disturbingly becoming “the new truth”. I think such historical revisionism should not go uncommented.
Would you care to set the record straight? The version of the story I know involves Scheme and actors, but also contains immutable messages, Erlang, and microservices (in that order). It’s not just about messages, but about the realization that stateless code can be packed into messages. Note that Wikipedia lists Kay in their history of object-oriented programming.
Rather than repeat the historical record, perhaps a place to start the historical journey is the following quote by Alan Kay…
“I don’t think I invented “Object-oriented” but more or less “noticed” what was really powerful about just making everything from complete computers communicating with non-command messages. This was all chronicled in the HOPL II chapter I wrote “The Early History of Smalltalk”.
This raises the question of who did invent it?
What exactly did Smalltalk add in terms of object orientation that did not already exist, other than “objects all the way down”?
Should object orientation be therefore viewed by an Alan Kay perspective of “it’s about messaging”, particularly because his context was effectively limited to the language, platform and environment that is Smalltalk?
Wow, so let’s see if I interpreted this chain of replies correctly:
“Wow, you’re wrong. You’re so wrong, it’s disturbing how wrong you are.”
“Okay, well where are we all wrong?”
“Oh, such impressive knowledge took me great effort to learn by trawling historic tomes by my lonesome, and you yourself should put in the same effort I did if you wish to become as enlightened as I.”
If so, I’m just going to pass on this conversation, and note, that at no point did I even claim Alan Kay invented OO, so I don’t understand what prompted this pedantic anti-Kay/messaging reply.
I’m voting this up although I have some deep reservations with it. It deserves to be discussed.
I think we’re doing two things here. First, we’re confusing the “how” with the “what”. “How” is the way in which I’m accomplishing some kind of goal, functional code or OO code. The second thing we’re conflating is the difference between an application and a system boundary. Although there’s room for disagreement, I’m going with applications as defined as compilation units. Systems are 1-n compilation units representing the various desires of groups of people. Postgres might be an application, ie it might compile into one thing, but it’s also a system, ie, it represents the desires of lots of database coders.
The deeper theoretical issue here is boundaries themselves, no matter whether it’s a function, app, system, or whatnot. This can be even more arbitrary than the difference between applications and systems, yet it’s critical if we’re ever going to talk about things inside and outside the boundary (which is what this author is doing)
The best I can provide here that’s not controversial (I think) is that code exists to do something, no matter how that code is put together. This means that boundaries are going to have to be defined by some sort of process analysis. This could be a use-case survey or a data-flow diagram. There are a lot of ways to describe behavior, but at the end of the day, no matter what the code is or how it’s constructed, it has to do the things that the process analysis says it must do. It follows then that boundaries are always going to be around some kind of quasi-functional description of what you want to do. I don’t see any other way of slicing the apple.
Perhaps a point of contention is that there seems to be an assumption that “applications” primarily exist to transform data and transfer it between them. That is a surely a narrow viewpoint? Given this, I think I understand the (current) attraction to the functional paradigm, as it particularly suits this assumption?
At the boundaries, applications are themselves objects, and the JSON you use to communicate with them are immutable messages. They, if we’re also talking (micro)services, are the closest thing to what Alan Kay envisioned as “objects”. (And similarly what exists in Erlang, if I’m not mistaken.)
Also, as a point:
Yes, well, state being bound up in a function would be a problem, but otherwise a pure stateless function is going to cross just fine. Assuming it executes in a limited context that has its dependencies. (Alternatively, you could transform said function into a single function of all its dependencies inlined.)
And, a function can include local data, as static information within itself. Of course, none of this is literally an object/closure with running state, but, if we wanted to get pedantic, we could totally send an image of a running process or module and spin it up on the other end, like communication via passing Lisp images, but that’s really stretching the imagination… or maybe an amusing thought exercise… At this point we’re reaching similar modeling of the biological world, and maybe Alan Kay, being a biologist, would find this amusing.
If we’re going to assume the remote has the right dependencies, why not just assume that the remote has the stateless function as well and just send the data that parameterizes the function? That’s basically how RPC works today (and has worked for a long time). It doesn’t seem very useful to be able to marshal functions but only to remotes which have the dependencies pre-installed. It seems like we shouldn’t assume dependencies are installed and either do our normal RPC stuff or we come up with a scheme for marshaling the dependencies over the wire as well (perhaps with some caching so we’re not marshaling them to remotes that already have them).
Moreover, regardless of whether we’re sending dependencies or not, sending stateless functions isn’t particularly easy in a natively compiled language because you’re assuming the remote has the same architecture and a compatible kernel (or libc in many cases). So you need to either need to enforce that invariant or else you need to keep a platform agnostic version of the function (e.g., source code or VM bytecode) and ship that which means some kind of compiler/runtime on the remote.
All of this seems to support the “not very well” characterization of marshaling closures and objects.
Of course the inventors of object-orientation would likely take issue with your deduction that microservices, immutable messages and Erlang best constitute their concepts (it wasn’t Alan Kay). This is taking the magical “it’s all about messaging” to an absurd extreme.
This implication that Alan Kay somehow invented objects is incorrect, yet disturbingly becoming “the new truth”. I think such historical revisionism should not go uncommented.
Would you care to set the record straight? The version of the story I know involves Scheme and actors, but also contains immutable messages, Erlang, and microservices (in that order). It’s not just about messages, but about the realization that stateless code can be packed into messages. Note that Wikipedia lists Kay in their history of object-oriented programming.
Rather than repeat the historical record, perhaps a place to start the historical journey is the following quote by Alan Kay…
“I don’t think I invented “Object-oriented” but more or less “noticed” what was really powerful about just making everything from complete computers communicating with non-command messages. This was all chronicled in the HOPL II chapter I wrote “The Early History of Smalltalk”.
Wow, so let’s see if I interpreted this chain of replies correctly:
If so, I’m just going to pass on this conversation, and note, that at no point did I even claim Alan Kay invented OO, so I don’t understand what prompted this pedantic anti-Kay/messaging reply.
I’m voting this up although I have some deep reservations with it. It deserves to be discussed.
I think we’re doing two things here. First, we’re confusing the “how” with the “what”. “How” is the way in which I’m accomplishing some kind of goal, functional code or OO code. The second thing we’re conflating is the difference between an application and a system boundary. Although there’s room for disagreement, I’m going with applications as defined as compilation units. Systems are 1-n compilation units representing the various desires of groups of people. Postgres might be an application, ie it might compile into one thing, but it’s also a system, ie, it represents the desires of lots of database coders.
The deeper theoretical issue here is boundaries themselves, no matter whether it’s a function, app, system, or whatnot. This can be even more arbitrary than the difference between applications and systems, yet it’s critical if we’re ever going to talk about things inside and outside the boundary (which is what this author is doing)
The best I can provide here that’s not controversial (I think) is that code exists to do something, no matter how that code is put together. This means that boundaries are going to have to be defined by some sort of process analysis. This could be a use-case survey or a data-flow diagram. There are a lot of ways to describe behavior, but at the end of the day, no matter what the code is or how it’s constructed, it has to do the things that the process analysis says it must do. It follows then that boundaries are always going to be around some kind of quasi-functional description of what you want to do. I don’t see any other way of slicing the apple.
Perhaps a point of contention is that there seems to be an assumption that “applications” primarily exist to transform data and transfer it between them. That is a surely a narrow viewpoint? Given this, I think I understand the (current) attraction to the functional paradigm, as it particularly suits this assumption?