5 ms·

In my opinion this is the most important insight into Smalltalk: that Smalltalk is renaming indirect function calls as "messages". If Smalltalk message passing

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
    When you write i := (j + 1) this is said to be sending a "+" message to j with argument 1. But how does the value get sent back to the assignment. For consistency, it ought to be j sending an assignment message to i with the the value. But how did j find out about i? The assignment message is sent to i, not j. Problem. So the Smalltalk convention is that each message sent produces a value. That value is determined by the recipient of the message; it's not just a send status code as in a real message passing system. Values break the message passing paradigm, and force the "message passing" to work like a function call. So there was no real reason not to implement them as function calls. Then there was no real reason not to think of them as function calls. A purer message passing approach would involve a callback when the result is available. That's how everything with a delay works in Javascript. It's a bit unwieldy to do that for every piece of computation, though. Real asynchronous messages are something else. Go uses them extensively. Then you have locking, race conditions, lockups, and all the problems of concurrency, but you can get multiple processors working on the problem.
    - jecel 10y ago
      In Smalltalk-72 and -74 the assignment (left arrow character) was a message just like any other. This became a special case in Smalltalk-76 and later and became just a message again in Self, where you wrote i: (j + 1) meaning self i: ( self j + 1 ) For tinySelf 1 I did implement each message using future objects. This is, as you say, slooooow to do for every piece of computation but there are implementation tricks that can optimize away all the cases where it is not really needed. http://www.merlintec.com/lsi/tiny.html http://www.merlintec.com/lsi/tiny.html
    - groovy2shoes 10y ago
      > So there was no real reason not to implement them as function calls. Then there was no real reason not to think of them as function calls. Indeed, and this was the insight discovered by Guy L. Steele Jr. while experimenting with implementing the Actor Model in Lisp, which was one of the insights that lead to the development of Scheme. At some point, while reading his code, he realized that actors and closures were implemented with roughly the same code, modulo alpha conversion, and thus a message pass was the same as a function call. Of course, the real message-passing called for by the Actor Model became more practical with the introduction of tail-call elimination, because that meant that the stack did not grow out of control as the actors delivered their results via messages to the next actor. I have a feeling that the discovery of closures-as-actors and the discovery of tail-call elimination went hand-in-hand, and possibly even continuation-passing style.
- gnaritas 10y ago
  > As a side effect, Simula was the first object-oriented language. No, Simula was the first language with objects; having objects does not make a language object oriented. Smalltalk was the first object oriented langauge, the object was the central metaphor upon which the entire language was built, unlike Simula which was a procedural language with objects grafted on. Kay made up the moniker object oriented to denote this distinction, the term literally exists to describe the difference between what Smalltalk was and what everything else was. It does not apply to Simula despite the persistence of this misunderstanding.

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
  When you write i := (j + 1) this is said to be sending a "+" message to j with argument 1. But how does the value get sent back to the assignment. For consistency, it ought to be j sending an assignment message to i with the the value. But how did j find out about i? The assignment message is sent to i, not j. Problem. So the Smalltalk convention is that each message sent produces a value. That value is determined by the recipient of the message; it's not just a send status code as in a real message passing system. Values break the message passing paradigm, and force the "message passing" to work like a function call. So there was no real reason not to implement them as function calls. Then there was no real reason not to think of them as function calls. A purer message passing approach would involve a callback when the result is available. That's how everything with a delay works in Javascript. It's a bit unwieldy to do that for every piece of computation, though. Real asynchronous messages are something else. Go uses them extensively. Then you have locking, race conditions, lockups, and all the problems of concurrency, but you can get multiple processors working on the problem.
  - jecel 10y ago
    In Smalltalk-72 and -74 the assignment (left arrow character) was a message just like any other. This became a special case in Smalltalk-76 and later and became just a message again in Self, where you wrote i: (j + 1) meaning self i: ( self j + 1 ) For tinySelf 1 I did implement each message using future objects. This is, as you say, slooooow to do for every piece of computation but there are implementation tricks that can optimize away all the cases where it is not really needed. http://www.merlintec.com/lsi/tiny.html http://www.merlintec.com/lsi/tiny.html
  - groovy2shoes 10y ago
    > So there was no real reason not to implement them as function calls. Then there was no real reason not to think of them as function calls. Indeed, and this was the insight discovered by Guy L. Steele Jr. while experimenting with implementing the Actor Model in Lisp, which was one of the insights that lead to the development of Scheme. At some point, while reading his code, he realized that actors and closures were implemented with roughly the same code, modulo alpha conversion, and thus a message pass was the same as a function call. Of course, the real message-passing called for by the Actor Model became more practical with the introduction of tail-call elimination, because that meant that the stack did not grow out of control as the actors delivered their results via messages to the next actor. I have a feeling that the discovery of closures-as-actors and the discovery of tail-call elimination went hand-in-hand, and possibly even continuation-passing style.
gnaritas 10y ago
> As a side effect, Simula was the first object-oriented language. No, Simula was the first language with objects; having objects does not make a language object oriented. Smalltalk was the first object oriented langauge, the object was the central metaphor upon which the entire language was built, unlike Simula which was a procedural language with objects grafted on. Kay made up the moniker object oriented to denote this distinction, the term literally exists to describe the difference between what Smalltalk was and what everything else was. It does not apply to Simula despite the persistence of this misunderstanding.