10 ms·

> Part of the idea behind “real objects” was to act as “virtual machines” connected by “neutral messages” in the very same way as we were starting to design th

> Part of the idea behind “real objects” was to act as “virtual machines” connected by “neutral messages” in the very same way as we were starting to design the Internet — and that the “virtual internet of objects” would map into the subsequent hardware network. The latter got made, and the former did not get understood or adopted. Can anyone elaborate what he means by this (and the overall idea of "real objects"?

noahlt 10y ago
"In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing "computer stuff" into things each less strong than the whole—like data structures, procedures, and functions which are the usual paraphernalia of programming languages—each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network." That's Alan Kay in The Early History of Smalltalk, which you might enjoy reading in full: http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/
- Animats 10y ago
  It isn't, though. Smalltalk "messages" are just function calls. It's not like all Smalltalk objects are running asynchronously, in parallel, with unsynchronized messages flowing around.
  - tailrecursion 10y ago
    In my opinion this is the most important insight into Smalltalk: that Smalltalk is renaming indirect function calls as "messages". If Smalltalk message passing were asynchronous, and if Smalltalk objects were processes, then Smalltalk would be closer to the vision that Kay conveys. I believe it was Jonathan Rees who emphasized the relationship between Smalltalk's messages and generic functions.
    - Animats 10y ago
      Smalltalk was descended from Simula, which was a variant of ALGOL-60 with discrete event simulation capabilities. As a side effect, Simula was the first object-oriented language. This confused things. Objects were associated with discrete event simulation, which led to the obsession with messages. Kay liked discrete event simulation - he thought that one of the big applications for personal computers was going to be simulation and scheduling. There's a little hospital simulation for the Alto shown in the Personal Dynamic Media book. In a discrete event simulator, there's a notion of time, and a simulated pseudo-clock, but in reality, all the events are sorted in time order and executed sequentially. (You can schedule something to happen in 2 seconds, but that just puts it in the event queue in the proper place.) Locking against concurrency is not required. This serialized notion of concurrency is more or less equivalent to just calling functions. Once people realized that object-oriented programming doesn't require discrete event simulation, the concepts parted company. OOP became more about encapsulation, although some languages still use the "message" terminology. So this is a historical artifact. Those happen. In von Neumann's EDVAC report, where he laid out the design for most modern computers, there's discussion of logic gates as simplified neurons and synapses. Nobody thinks of logic gates that way any more, and we now know that neurons don't work like logic gates. But at the time, people thought of them as similar.
      - jecel 10y ago
        Messages were clearly not fancy subroutine calls in Smalltalk-72 and -74: they were a stream of tokens between the sender and the receiver. This was optimized away in Smalltalk-76 (and so -78 and -80) so that messages no longer seemed like the ones in Actor languages or Erlang. But I don't think it is unfortunate that the name "messages" has persisted. Check out Squeak running on a 56 core Tilera chip with the RoarVM. Messages from an object to another one in the same core are indeed just fancy subroutine calls. But if the receiver is in a different core, then a message is a bunch of bytes sent from one core to the other. Even though the two messages are the same at the source level and at the bytecode level.
        Animats 10y ago
  - e12e 10y ago
    I'm not sure that's a meaningful distinction without more detail. An x86 "function call" is a push, a jump, logic, a push and a return jump (same for a procedure call). A "message" is something you can (more) easily adapt to be something sent over the network. In a high-level system, the distinction between a "function call" and RPC can also dissappear - but does it really matter if it is messaging that is like (abstract/high level) function calls or the other way around? Consider if the ("x86") function call ends up being a jump from an x86 core on a server to an arm chip on a phone - it doesn't work. But a phone might very well respond to a "getId" message. Might return a phone number or an ip address for example.
bluetomcat 10y ago
I interpret it as message passing between independent computing entities. For example, having a global object called "google" and an associated message "ask", or an object "HSBCBank" with a method "getMonthlyStatement". Instead, we started to apply OO principles from a software engineering point of view, in order to write big monoliths.
- philippeback 10y ago
  The message send is actually an object in Smalltalk. So, in process, out of process, to another box, this shouldn't matter. For performance reasons, all kinds of optimizations are present. In Pharo (http:/pharo.org), which is "Smalltalk inspired", there are new developments like the remote debugger: http://dionisiydk.blogspot.be/2016/07/remote-debugging-tools-is-ready.html http://dionisiydk.blogspot.be/2016/07/remote-debugging-tools... It is based on Seamless.
  - gnaritas 10y ago
    Pharo isn't Smalltalk inspired, Pharo is a Smalltalk, one of several; it forked from Squeak to create a more business oriented Smalltalk rather than the garish toy for children that Squeak was.
tailrecursion 10y ago
Real objects are processes. Alan Kay has had many opportunities to specify precisely what he means by objects and messages, and based on reading his more recent (or less old) VRI papers, Kay draws inspiration for objects from biology, where swarms of molecules pattern match against the partially constructed molecule and build it up step by step. I've seen him give an example in only one paper. Needless to say this is not how Smalltalk works.
- groovy2shoes 10y ago
  > Needless to say this is not how Smalltalk works. I've always gotten the strangest feeling that Mr. Kay made up the distinction between Smalltalk and later OOP languages after the fact. I think this is precisely the reason I get that feeling: because despite what Mr. Kay says about Smalltalk and OO, programming in Smalltalk feels very much like programming in any other OO language. I don't mean any disrespect to Mr. Kay. I give him the benefit of the doubt in assuming that his intended language was different from the language that actually materialized, likely due to implementation issues. In that regard, as a language designer I can very much sympathize.
digi_owl 10y ago
OOP came out of early "supercomputer" simulation work. Best i can tell, the idea is that each object should be possible to be assigned one or more CPU core (with each running a instance of the object). This then maximizing the performance of the simulation.
rektide 10y ago
I tend to think this means that the objects ought have a manageability and reality unto themselves, and be portable and manipulable beyond the application. Instead of objects being a structure inside of a single process that manipulates the object, objects are general entities that exist broadly on a system. All things on the system use a neutral messaging format to talk to objects, getting data or asking for the object to run operations.

noahlt 10y ago

"In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing "computer stuff" into things each less strong than the whole—like data structures, procedures, and functions which are the usual paraphernalia of programming languages—each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network." That's Alan Kay in The Early History of Smalltalk, which you might enjoy reading in full: http://worrydream.com/EarlyHistoryOfSmalltalk/ http://worrydream.com/EarlyHistoryOfSmalltalk/

Animats 10y ago
It isn't, though. Smalltalk "messages" are just function calls. It's not like all Smalltalk objects are running asynchronously, in parallel, with unsynchronized messages flowing around.
- tailrecursion 10y ago
  In my opinion this is the most important insight into Smalltalk: that Smalltalk is renaming indirect function calls as "messages". If Smalltalk message passing were asynchronous, and if Smalltalk objects were processes, then Smalltalk would be closer to the vision that Kay conveys. I believe it was Jonathan Rees who emphasized the relationship between Smalltalk's messages and generic functions.
  - Animats 10y ago
    Smalltalk was descended from Simula, which was a variant of ALGOL-60 with discrete event simulation capabilities. As a side effect, Simula was the first object-oriented language. This confused things. Objects were associated with discrete event simulation, which led to the obsession with messages. Kay liked discrete event simulation - he thought that one of the big applications for personal computers was going to be simulation and scheduling. There's a little hospital simulation for the Alto shown in the Personal Dynamic Media book. In a discrete event simulator, there's a notion of time, and a simulated pseudo-clock, but in reality, all the events are sorted in time order and executed sequentially. (You can schedule something to happen in 2 seconds, but that just puts it in the event queue in the proper place.) Locking against concurrency is not required. This serialized notion of concurrency is more or less equivalent to just calling functions. Once people realized that object-oriented programming doesn't require discrete event simulation, the concepts parted company. OOP became more about encapsulation, although some languages still use the "message" terminology. So this is a historical artifact. Those happen. In von Neumann's EDVAC report, where he laid out the design for most modern computers, there's discussion of logic gates as simplified neurons and synapses. Nobody thinks of logic gates that way any more, and we now know that neurons don't work like logic gates. But at the time, people thought of them as similar.
    - jecel 10y ago
      Messages were clearly not fancy subroutine calls in Smalltalk-72 and -74: they were a stream of tokens between the sender and the receiver. This was optimized away in Smalltalk-76 (and so -78 and -80) so that messages no longer seemed like the ones in Actor languages or Erlang. But I don't think it is unfortunate that the name "messages" has persisted. Check out Squeak running on a 56 core Tilera chip with the RoarVM. Messages from an object to another one in the same core are indeed just fancy subroutine calls. But if the receiver is in a different core, then a message is a bunch of bytes sent from one core to the other. Even though the two messages are the same at the source level and at the bytecode level.
      - Animats 10y ago
- e12e 10y ago
  I'm not sure that's a meaningful distinction without more detail. An x86 "function call" is a push, a jump, logic, a push and a return jump (same for a procedure call). A "message" is something you can (more) easily adapt to be something sent over the network. In a high-level system, the distinction between a "function call" and RPC can also dissappear - but does it really matter if it is messaging that is like (abstract/high level) function calls or the other way around? Consider if the ("x86") function call ends up being a jump from an x86 core on a server to an arm chip on a phone - it doesn't work. But a phone might very well respond to a "getId" message. Might return a phone number or an ip address for example.

bluetomcat 10y ago

I interpret it as message passing between independent computing entities. For example, having a global object called "google" and an associated message "ask", or an object "HSBCBank" with a method "getMonthlyStatement". Instead, we started to apply OO principles from a software engineering point of view, in order to write big monoliths.

philippeback 10y ago
The message send is actually an object in Smalltalk. So, in process, out of process, to another box, this shouldn't matter. For performance reasons, all kinds of optimizations are present. In Pharo (http:/pharo.org), which is "Smalltalk inspired", there are new developments like the remote debugger: http://dionisiydk.blogspot.be/2016/07/remote-debugging-tools-is-ready.html http://dionisiydk.blogspot.be/2016/07/remote-debugging-tools... It is based on Seamless.
- gnaritas 10y ago
  Pharo isn't Smalltalk inspired, Pharo is a Smalltalk, one of several; it forked from Squeak to create a more business oriented Smalltalk rather than the garish toy for children that Squeak was.

tailrecursion 10y ago

Real objects are processes. Alan Kay has had many opportunities to specify precisely what he means by objects and messages, and based on reading his more recent (or less old) VRI papers, Kay draws inspiration for objects from biology, where swarms of molecules pattern match against the partially constructed molecule and build it up step by step. I've seen him give an example in only one paper. Needless to say this is not how Smalltalk works.

groovy2shoes 10y ago
> Needless to say this is not how Smalltalk works. I've always gotten the strangest feeling that Mr. Kay made up the distinction between Smalltalk and later OOP languages after the fact. I think this is precisely the reason I get that feeling: because despite what Mr. Kay says about Smalltalk and OO, programming in Smalltalk feels very much like programming in any other OO language. I don't mean any disrespect to Mr. Kay. I give him the benefit of the doubt in assuming that his intended language was different from the language that actually materialized, likely due to implementation issues. In that regard, as a language designer I can very much sympathize.

digi_owl 10y ago

OOP came out of early "supercomputer" simulation work. Best i can tell, the idea is that each object should be possible to be assigned one or more CPU core (with each running a instance of the object). This then maximizing the performance of the simulation.

rektide 10y ago

I tend to think this means that the objects ought have a manageability and reality unto themselves, and be portable and manipulable beyond the application. Instead of objects being a structure inside of a single process that manipulates the object, objects are general entities that exist broadly on a system. All things on the system use a neutral messaging format to talk to objects, getting data or asking for the object to run operations.