Smalltalk

Since your comment is flagged to death, I'll leave this here for a more hands on approach for interested people: https://interlisp.org/ is one of the systems which ran on these machines at the time. Due to the stars aligning right in a syzygy it is now available as open-source, updated to run on modern systems. Even in a browser, without installing it. Another one would be https://cuis.st/ which is the nearest Smalltalk-80 like thing available. Not as toyish as Squeak, not as bloated as Pharo. Or even more 'original': https://github.com/rochus-keller/Smalltalk

You have to consider that there is actually no true message passing in Smalltalk. Smalltalk just uses that term for dynamic dispatch of compiled methods and calling them (synchronous local invocation). Since Smalltalk 76 methods are compiled and there is a dynamic dispatch mechanism similar to Simula 67 (or Java); the main difference is that Smalltalk uses an internalized pointer to the selector (i.e. method signature) for dispatch instead of the more efficient method index used by Simula 67 and most modern OO-languages (including Java); essentially all OO languages support late binding. When you read e.g. https://dl.acm.org/doi/10.1145/3386335 (highly recommended), Ingalls describes that the first Smalltalk implementation in 1972 was a bit closer to "message passing" in that token streams were sent to an object for interpretation, but th

I assume you mean this project: https://github.com/rochus-keller/Smalltalk/ It's about a Smalltalk-80 image from 1983. Trellis/Owl had interesting ideas, though I spent more time with Modula-3.

> You can run Smalltalk on bare metal, if you want. Yes, if you provide the kernel, which implements all madatory primitives (i.e. system calls) required by the Smalltalk code to work. In the early Alto days, these were implemented in Alto microcode. The characterization of Smalltalk as "running on bare metal" oversimplifies the actual system architecture. In reality, the microcode implementation of the VM served as the effective operating system kernel; this microcode layer handled essential system functions including drive access and display buffer management; Smalltalk ran on top of this microcode layer, not directly on the hardware. Smalltalk is essentially the userland of an operating system, if we compare it to Unix; it's a more primitive system compared to Unix though, since the "kernel" only has one process, no process manager wit

Strange. I even works with my 2009 EliteBook with Firefox. Maybe try this link: https://github.com/rochus-keller/Smalltalk/blob/master/Readm...

Well, I still prefer https://github.com/rochus-keller/Smalltalk/#a-smalltalk-80-c...

> what the author plans to use it for Thanks. I e.g. re-implemented the Smalltalk-80 VM in Luon (see https://github.com/rochus-keller/Smalltalk/), and I consider implementing an Interlisp VM (see https://github.com/rochus-keller/gingko/) which uses LuaJIT, which was an important motivation to interrupt my Micron language project to implement Luon.

Thanks. I know SOM and Smalltalk pretty well and have implemented several VMs myself (see https://github.com/rochus-keller/Som/ and https://github.com/rochus-keller/Smalltalk/). SOM was originally designed and implemented by Bak and Lund at Aarhus university. It's very well suited for performance experiments and shares with Smalltalk the relevant features. There is an implementation of the Are-we-fast-yet suite for both SOM and Smalltalk.

> Self wasn't sufficiently fast? Self apparently is sufficiently different from Smalltalk-80 so that even today JS engines (which are descendants of the Self engine) are still significanly faster than Cog/OpenSmalltalk. Remember that also Python is known to be pretty resistant to performance improvements. So some languages/VMs apparently are more amenable than others. In my referenced report you can see that there is still nearly a factor two between Pharo (using OpenSmalltalk) and Node.js (using V8). But Pharo is at least faster than LuaJIT, which again is about factor 220 faster than a Smalltalk interpreter which does the caching and inlining described in the Bluebook. So Cog/OpenSmalltalk went a long way to finally be the fastest Smalltalk engine around. A comparison with Smalltalk 72 makes little sense because it was a completely diff

Interesting talk. Smalltalk (like Lisp) has indeed a very simple (i.e. minimal) syntax. But that doesn't necessarily mean that it is also simple to write and read code, or to implement an efficient compiler. E.g. blocks - as great as they are - make inlining very difficult; it eventually took 30 years to implement a VM with decent performance (see http://software.rochus-keller.ch/are-we-fast-yet_crystal_lua... for the results of https://github.com/rochus-keller/Som/ and https://github.com/rochus-keller/Smalltalk/ compared to Cog/OpenSmalltalk). Another language explicitly designed for simplicity is e.g. Oberon, which is statically typed and easier to implement with decent performance. In my experience, at the end of the day, it's more the familiarity with a language that makes it seem "simple". And there is a trade-off between "simplicity

> Smalltalkish Have a look at the SOM dialect which is successfully used in education: http://som-st.github.io/ Here is an implementation in C++ which runs on LuaJIT: https://github.com/rochus-keller/Som/ > unfortunately out of print book Smalltalk 80: the language and its implementation is commonly recommended I assume you know this link: http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.... Here is an implementation in C++ and Lua: https://github.com/rochus-keller/Smalltalk

> I'm assuming the "by the Bluebook" implementation they're referring to is this: Or this: https://github.com/rochus-keller/Smalltalk/

> Actually even ST-72 made synchronous calls I've not suggested it is anything but synchronous, so I don't know why you're bringing that up. It's not what we're talking about when we talk about "message passing" in this context. > In ST-76 and later versions "message passing" is just nomenclature used by the ST folks for something that is just ordinary method dispatch and call (if you have doubts, you can analyze the innards of the ST-80 VM yourself e.g. with these tools: https://github.com/rochus-keller/Smalltalk ). Sure, you can implement method dispatch the same way. I've written a (partial; unfinished; very buggy) Ruby compiler that allows dynamic method redefinition with even basic C++-style vtables. The point is not the dispatch method but the ability to override them at will. > The major difference is the dispatch based on signatur

> message passing and late binding combined. "Duck typing" is seriously diminishing it Actually even ST-72 made synchronous calls, but at least with a token stream interpreted by the receiving object (thus at least a bit of "message passing"). In ST-76 and later versions "message passing" is just nomenclature used by the ST folks for something that is just ordinary method dispatch and call (if you have doubts, you can analyze the innards of the ST-80 VM yourself e.g. with these tools: https://github.com/rochus-keller/Smalltalk ). The major difference is the dispatch based on signature hash (similar to e.g. Java interface method calls) instead of static offsets, which enables late binding (at the expense of performance); and since everything including ordinary integers derive from Object, all values and objects are subject to dynamic metho

In Smalltalk-80 they're on the left side, see e.g. https://github.com/rochus-keller/Smalltalk As is known, Jobs was inspired by the Smalltalk GUI.