3 ms·

"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—

by 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
        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
- 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.

by noahlt 10y ago

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
      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
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.