5 ms·

For another take on Smalltalk, we covered it as a retro-future episode on our podcast. https://www.youtube.com/watch?v=FZNqOFAhM8o https://www.youtube.com/watch

by iamwil 4y ago

For another take on Smalltalk, we covered it as a retro-future episode on our podcast. https://www.youtube.com/watch?v=FZNqOFAhM8o https://www.youtube.com/watch?v=FZNqOFAhM8o Some of what we covered: - OOP is message passing - The interactive environment - Surprising things about Smalltalk - Did Smalltalk achieve its goals? - Failure of Enterprise Smalltalk

Rochus 4y ago
> OOP is message passing No longer true since Smalltalk-76, which has virtual method dispatch like Java. What you refer to is probably Kay's philosophy which is something else than the Smalltalk implementation we know today.
- 0x445442 4y ago
  Can you elaborate on this because this has been bugging me for some time. I’ve heard Kay’s comment many times but I have never heard him give an explanation as to what practical difference it would make in the day to day task of software development, specifically with respect to Smalltalk 80. When I think of message passing I think of things like Kafka, message queues, ESBs etc. Where the producers and consumers of the messages are completely decoupled and the processing is asynchronous. But I’m not sure how this maps to a thread/proc local context where a caller of a function or method or the sender of a “message” expects a response.
  - Rochus 4y ago
    Kay's view of object-orientation is "messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things" (quoted from http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...). This is quite different from what we associate with object-orientation today (objects, classes, inheritance, virtual methods, etc.), and how it was implemented e.g. in Simula 67, or in Java. Kay's view has similarities with Hewitt's actor model (see e.g. https://www.quora.com/What-is-the-difference-between-Alan-Kays-definition-of-OOP-and-Carl-Hewitts-Actor-Model/answer/Alan-Kay-11 https://www.quora.com/What-is-the-difference-between-Alan-Ka...). A good source on how Smalltalk-72 was different from Smalltalk-76 is Ingall's 2020 paper (https://dl.acm.org/doi/10.1145/3386335 https://dl.acm.org/doi/10.1145/3386335). Smalltalk-72 indeed implemented a kind of message passing in that there were objects "sending" token streams to other objects which interpreted these streams; so there was indeed something like a "message", and there are similarities with message queues and parts of Kafka; message passing can be synchronous or asynchronous. Calling a method is not the same as passing a message; there is no message which has to be "interpreted", but the compiler knows the signature of the method and generates efficient code for calling it using a specific ABI. If methods from objects are called which reside in a different address space/process or even on different hardware, then method calls are dispatched over an IPC mechanism or even a network (like e.g. CORBA or some versions of ESBs); the network dispatch is technically message passing, but to the programmer it still looks like a local (synchronous) method call. The Smalltalk community instead prefers to talk about "message passing", even if it is implemented as plain in-process, in-memory method call. It is also notable that already Simula I (1962) had "active objects" (the Simula I objects were called "process") and there was the notion of events and queues.
- coldtea 4y ago
  You're talking about the internals and optimizations. Smalltalk still uses message passing as the concept, even if it doesn't send an actual a message for the recipient to parse under the covers. That's how you can trivially have distributed objects, instances responsing to methods they don't directly declare and know about, etc.
  - Rochus 4y ago
    Well, a dog is still a dog, even if we call it bird ;-)
    - igouy 4y ago
      > No longer true since Smalltalk-76 Not even 5 perform: #factorial ?
      - Rochus 4y ago
        "perform" is a method of the Object (i.e. Integer super) class, the argument is a symbol; this call just does a second method dispatch, i.e. "perform" does yet another dispatch on the Integer object and then calls the "factorial" method; so no, neither this is message passing; it's rather like Object.getClass().getMethod() and Method.invoke() in Java.
        igouy 4y ago
        I suppose it depends on how we define "true" message passing.
        Rochus 4y ago
        A general problem of human communication. But there is also a pertinent body of knowledge that is taught and tested at universities, which includes an accepted terminology. The relevant classes in the Smalltalk-80 source code are even called "CompiledMethod" and "MethodDictionary". See also primitivePerformWithArgs, lookupMethodInClass and executeNewMethod in part 4 of the bluebook.

by iamwil 4y ago

Rochus 4y ago

> OOP is message passing No longer true since Smalltalk-76, which has virtual method dispatch like Java. What you refer to is probably Kay's philosophy which is something else than the Smalltalk implementation we know today.

0x445442 4y ago
Can you elaborate on this because this has been bugging me for some time. I’ve heard Kay’s comment many times but I have never heard him give an explanation as to what practical difference it would make in the day to day task of software development, specifically with respect to Smalltalk 80. When I think of message passing I think of things like Kafka, message queues, ESBs etc. Where the producers and consumers of the messages are completely decoupled and the processing is asynchronous. But I’m not sure how this maps to a thread/proc local context where a caller of a function or method or the sender of a “message” expects a response.
- Rochus 4y ago
  Kay's view of object-orientation is "messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things" (quoted from http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...). This is quite different from what we associate with object-orientation today (objects, classes, inheritance, virtual methods, etc.), and how it was implemented e.g. in Simula 67, or in Java. Kay's view has similarities with Hewitt's actor model (see e.g. https://www.quora.com/What-is-the-difference-between-Alan-Kays-definition-of-OOP-and-Carl-Hewitts-Actor-Model/answer/Alan-Kay-11 https://www.quora.com/What-is-the-difference-between-Alan-Ka...). A good source on how Smalltalk-72 was different from Smalltalk-76 is Ingall's 2020 paper (https://dl.acm.org/doi/10.1145/3386335 https://dl.acm.org/doi/10.1145/3386335). Smalltalk-72 indeed implemented a kind of message passing in that there were objects "sending" token streams to other objects which interpreted these streams; so there was indeed something like a "message", and there are similarities with message queues and parts of Kafka; message passing can be synchronous or asynchronous. Calling a method is not the same as passing a message; there is no message which has to be "interpreted", but the compiler knows the signature of the method and generates efficient code for calling it using a specific ABI. If methods from objects are called which reside in a different address space/process or even on different hardware, then method calls are dispatched over an IPC mechanism or even a network (like e.g. CORBA or some versions of ESBs); the network dispatch is technically message passing, but to the programmer it still looks like a local (synchronous) method call. The Smalltalk community instead prefers to talk about "message passing", even if it is implemented as plain in-process, in-memory method call. It is also notable that already Simula I (1962) had "active objects" (the Simula I objects were called "process") and there was the notion of events and queues.
coldtea 4y ago
You're talking about the internals and optimizations. Smalltalk still uses message passing as the concept, even if it doesn't send an actual a message for the recipient to parse under the covers. That's how you can trivially have distributed objects, instances responsing to methods they don't directly declare and know about, etc.
- Rochus 4y ago
  Well, a dog is still a dog, even if we call it bird ;-)
  - igouy 4y ago
    > No longer true since Smalltalk-76 Not even 5 perform: #factorial ?
    - Rochus 4y ago
      "perform" is a method of the Object (i.e. Integer super) class, the argument is a symbol; this call just does a second method dispatch, i.e. "perform" does yet another dispatch on the Integer object and then calls the "factorial" method; so no, neither this is message passing; it's rather like Object.getClass().getMethod() and Method.invoke() in Java.
      - igouy 4y ago
        I suppose it depends on how we define "true" message passing.
        Rochus 4y ago
        A general problem of human communication. But there is also a pertinent body of knowledge that is taught and tested at universities, which includes an accepted terminology. The relevant classes in the Smalltalk-80 source code are even called "CompiledMethod" and "MethodDictionary". See also primitivePerformWithArgs, lookupMethodInClass and executeNewMethod in part 4 of the bluebook.