Smalltalk VS squeak.org

> * I'm assuming the "by the Bluebook" implementation they're referring to is this: *

Or this: https://github.com/rochus-keller/Smalltalk/

> 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 positions, 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 method dispatch; it's no coincidence that Smalltalk was the first language to allow real duck typing. The unification of scalar values and references, dynamic typing, and likewise the minimal syntax where control structures are implemented by means of runtime constructs were already known from Lisp; also closures (i.e. ST blocks) were already known before they were added to ST.

Here is one even in Lua: https://github.com/rochus-keller/Smalltalk/

> 10kSLOC for the entire universe

It is the nature of idealists that they see the world idealized. Smalltalk-80 itself has nearly 30 kSLOC; it's just more difficult to count, but I wrote tools which can do it (https://github.com/rochus-keller/Smalltalk/).

Why should "perform" be a message? It's just a method of the Object class, which is the superclass of Integer. You can use my St80ClassBrowser and St80ImageViewer (see https://github.com/rochus-keller/Smalltalk/) to check the ST-80 source code and image if you want; there is a list of all selectors and the classes which implement them. Going up the class hierarchy when doing virtual method dispatch is a fundamental concept of all object-oriented implementations; in contrast to e.g. C++ this can be done dynamically at runtime in Smalltalk or Java (which is also called late binding). In contrast to Smalltalk in Java the class loader verifies that a method for the referenced signature actually exists; in Smalltalk you can try to dispatch any signature which can result in a call to the doesNotUnderstand method of the Object class.

> a large lua game code base, over 4000 files, 1.5 million lines of code

Interesting; how do you manage to keep consistency? Do you have special tools to e.g. detect inadvertent global variables? I once wrote a Smalltalk VM in Lua (https://github.com/rochus-keller/Smalltalk/blob/master/Inter...) which is a much smaller code base but even with this size I quickly would have lost track of e.g. scopes and names without tools I had to write myself (https://github.com/rochus-keller/LJTools).

It is true, that there is uncollected garbage in the original Xerox ST80 image. I've built some tools to analyze the image and also a VM which can be interrupted at any time to analyze the current state of the image (see https://github.com/rochus-keller/Smalltalk).

There are two zombie processes (OID 6662 and 19ba). There are also a couple of BlockContext and MethodContext which have a nil sender and a reference to an unknown method, but which are still referenced from somewhere (i.e. the collection is prevented even if it is not implemented by reference counting. E.g. OID 79a2 of class BinaryChoice. I have a full list if anybody is interested.

Integers are actually directly stored, i.e. without boxing/indirection by a pointer. The Smalltalk object memory doesn't have pointers in the C sense, but rather indices into the object table. If you're interested I've implemented a couple of tools to study the original Smalltalk-80 VM, see https://github.com/rochus-keller/Smalltalk/.

- https://github.com/rochus-keller/Smalltalk/ Parser, code model, interpreter and navigable browser for the original Xerox Smalltalk-80 v2 sources and virtual image file

- https://github.com/rochus-keller/Som/ Parser, code model, navigable browser and VM for the SOM Smalltalk dialect

- https://github.com/rochus-keller/Simula A Simula 67 parser written in C++ and Qt

> do you regret those endeavours?

No, not in any way; the projects were very entertaining and gave me interesting insights.

Also, it's not really an "operating system", nor was it implemented by the ST. It's just part of Squeak (you got the name right), the "engine" Scratch 1.x was made with (which lets you edit the code in the same window it's running in).

Just downloaded https://squeak.org/ to play around with this concept.

I wonder if there is already a modern tool/suite for Node/Python inspired by Smalltalk...

AFAIK the major SmallTalk distributions are https://squeak.org/ and https://pharo.org/. I've heard that Pharo is more complex and "practical", while Squeak is more educational and beginner-friendly. But both stick to their roots with "everything is an object or method", extreme reflection, and integrated runtime/IDE.

Your concept looks nice, it reminds me a bit of the Lisperati: https://www.hackster.io/news/the-lisperati1000-is-a-cyberdec...

So, did you consider Lisp or maybe Smalltalk? Plan 9 or Inferno might also be options.

Plan 9 comes in different variants, the "classic" one (with a Raspberry Pi port by Richard Miller) or 9front, an Inferno porting tutorial can be found at https://github.com/yshurik/inferno-rpi

Lisp and Smalltalk can run with or without Linux underneath, e.g. on the Raspberry Pi.

Bare-metal Lisp is available with interim: http://interim-os.com

Finally, bare-metal Smalltalk is available in my crosstalk system: https://github.com/michaelengel/crosstalk

Of course, Lisp and Smalltalk can also run hosted under Linux, e.g. using Squeak (https://squeak.org), Pharo (https://pharo.org) or InterLisp (https://github.com/Interlisp/medley).

Or - a crazy idea - build an emacs-only machine. That would be fun! :)

This repository contains multiple projects closely related to (hardware-accelerated) rendering in Squeak/Smalltalk.

Packages related to using OpenGL in Squeak/Smalltalk.

Author here, feel free to ask any questions you have :).

It's amazing this little project shows up again here. So far, I received a lot of very positive and friendly feedback about this little pet project of mine.

The whole project would not have been possible without the work of Rene Stange, who created the circle bare-metal library for the Raspberry Pi (https://github.com/rsta2) and Dan Banay, who created a C++ implementation of the Smalltalk-80 VM (https://github.com/dbanay/Smalltalk). I mostly hacked together some glue code...

If you want to dig deeper, the Blue Book by Adele Goldberg and David Robson (scan provided by Stephane Ducasse, thanks a lot!) is _the_ reference on both the language and the structure and implementation of the underlying bytecode VM: http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....

Beware, though it's fully functional, crosstalk is still limited by constraints of the original Smalltalk 80 system - e.g. in terms of color (black and white only), possible screen resolution (2^20 pixels, the system crashes if you try to increase the resolution beyond this) and available memory (~1 MB!).

Nevertheless, I think it's a rather authentic reproduction of a more than 40 year old system and I learned (in a comment thread on a completely different topic) that one of our fellow hackernews regulars used it to teach his kid Smalltalk programming - love it! I haven't tried to optimize it significantly, so there's no JIT compiler or bitblit acceleration using the Raspberry Pi GPU.

There's a more modern bare-metal Smalltalk implementation based on Squeak (https://squeak.org) for the Raspberry Pi by Pablo Marx, though this seems to have some stability problems according to the author: https://github.com/pablomarx/RaspberrySqueak

Finally, if you are interested in alternative bare-metal language/OS environments for the Raspberry Pi, you could also give Lukas Hartmann's (of MNT Reform notebook fame) Interim OS a try: http://interim-os.com

Came here to mention Smalltalk. In things like Smalltalk-80 and Squeak, there was no build system, there are no source code files, there isn't anything but the Smalltalk Development Environment. With something like ENVY/Developer, building involved generating an exported image from the environment.

If OP wants to try it: https://squeak.org/

She missed the biggest ‚programming portal‘ of all: Squeak (Smalltalk) (https://squeak.org/)

Inspecting objects, ‚live‘ coding, a GUI that's intimately tied to its CLI - that's exactly Squeak!

The Morphic UI: http://wiki.squeak.org/squeak/1870