The evolution of Smalltalk: from Smalltalk-72 through Squeak

its authors). > If you are doing whole-system development and have control over the entire thing, then it is that simple The dispatch mechanism and the described duality is the same, whether whole-system or not. > Kay's view of OO is a matter of "open world" versus "closed world" Smalltalk was always a "closed world" (you are always in the same image, but code can be compiled on the fly at runtime), and all calls were synchronous. Since the Oberon compiler and system treats each module as a dynamic loadable entity and supports loading by name, it actually supports the "open world" approach. Interestingly, Kay's view is likely best represented in Erlang, where there are true messages sent asynchronously. > If you're programming every operation with switch statements that select code paths based on objects' type tags As mentioned, Oberon traverses the "2D matrix" from the other side. Each module may or may not handle a message in a WITH (i.e. switch by type) statement, but modules per se ar dynamic. So the "a priori knowledge" only applies to the message type.

responsible for painting the border, had a width that was. . . wait a minute. . . a Fraction? We did not even have fractions in the student system, but she said, "Oh yes, I added a Fraction class". Interestingly, BitBlt was written to be resilient, in that if it received a non-integer argument, it would call itself again after sending the message asInteger to that argument. However, her fractions did not have such a method, so the debugger had stopped at that point and was not even able to show the problem because of another such infraction (er, sorry). I asked whether she had a conversion to integer and she replied no, but that her fractions did have a makeFloat message. We talked about the problem, and I got her to suggest defining Fraction understands: 'asInteger' as: '↑ self makeFloat asInteger' We were able to type this into the emergency evaluator, at which point the debugger miraculously displayed itself, the window she had tried to reframe reappeared, and everything in the system seemed to work again. Probably hundreds of methods in the system were now operating just fine with rectangles whose coordinates were instances of a student’s newly defined Fraction class. This illustrates the astounding ability of message-sending systems to absorb unanticipated constructions.` Daniel Ingalls "The Evolution of Smalltalk" 85:63 Proc. ACM Program. Lang., Vol. 4, No. HOPL, Article 85. Publication date: June 2020 https://dl.acm.org/doi/pdf/10.1145/3386335

found Swift Optionals easier to pick up. —Structural typing existed in dynamic languages, as he acknowledges. I'm actually not sure that Lisp got to images first. Smalltalk is younger than Lisp but old enough that Lisp was still evolving. According to The Evolution of Smalltalk [0], the very first version of Smalltalk had images. I'd be curious as to whether the author or anyone else has a good source on the first Lisp with images? [0]: https://dl.acm.org/doi/10.1145/3386335

bit closer to "message passing" in that token streams were sent to an object for interpretation, but that was synchronous and local as well (like the later method dispatch) and the objects were not "active" (in contrast to e.g. the Actor Model as implemented e.g. in Erlang). I spent a lot of time building tools to study the internals of Smalltalk-80; if you are interested in the technicalities, here is the link: https://github.com/rochus-keller/Smalltalk/.

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.