Pharo 12

Interesting, I'll have to take a look at that when I have some time. I may have missed that the first time around. Thanks!

Cuis [1] is a simplified fork of Squeak, trying to make it more closely resemble the original Smalltalk-80 (while using a custom version of Morphic). Squeak itself initially tried to not be bound by Smalltalk-80 heritage. Now, it focuses on preserving of the experiments that Alan Kay, Dan Ingalls, and others did, being very conservative in this regard. Pharo forked to have a system that can actually evolve.

Pharo should generally work on Wayland, so there will be more things going on, probably.

[1] https://cuis.st/

> Their lineage goes back to the Alto when people were imagining what interacting with computers even meant, and what metaphors from the real world make sense to apply to collections of bytes.

I would argue that this lineage of computing isn't as arcane and out-of-reach as people might think.

Much of the "obvious" promise of Smalltalk / object-based runtime environments — specifically, all the UI stuff it enabled — was too expensive / high-overhead initially, for it to have much penetration in the microcomputer or the mainframe/batch processing space; thus relegating those specific ideas to academic experiments in workstation productivity.

But fancy object-based UIs weren't the whole of what this lineage of computing was about. Microcomputer and mainframe systems were built as descendants of this lineage, repeatedly, and many of them were even in common use; but it might be harder to recognize them as such. It's the less-obvious, more low-level/internal architectural things they inherited.

If you ignore the specific assumption of a UI or "strict" OOP, and instead just consider this lineage as anything fitting these criteria:

1. systems that booted into a live runtime bytecode VM, usually de-hibernating the VM state from a memory image;

2. and then exposing a shell that was more of a REPL than a command language, allowing interoperation with the data that defined the state of the VM on a high level,

3. where the "operating system" within the runtime is fully exposed to you (rather than being a black box with a whitelisted FFI API); but where each data structure within that "operating system" is protected due to the common runtime of the OS + userland, enforcing ADT-defintion-time abstraction layers in the way it allows clients (including the REPL) to interact with any given object/ADT...

...then you could say that all of the following are part of the lineage:

• BASIC — especially the BASICs on microcomputers that booted to BASIC, or had BASIC on ROM, and never ran DOS (published software for these computers, was usually just precompiled BASIC bytecode!)

• Object Pascal / Delphi

• Emacs

• most SQL databases, but especially Ingress

• MOOs (object-oriented MUDs)

• Plan 9, despite its Unix roots. (Especially applicable insofar as you could consider "a runtime and OS as toolkit, and applications as LEGO with clear exposed seams that the user can pick apart and remix" an additional criterion.)

You can usually recognize these systems, because there's no way to get anything like a machine-code monitor / debugger on them; instead, the runtime itself usually exposes bytecode-level (or interpreter-level) monitoring / debugging, in a way that doesn't allow you to break the runtime's assumptions through it.

> to learn a whole new set of tools

The tools are how we find functionality that can be re-used and re-purposed to do what we need. A lot of exploring and reading existing stuff, less writing new stuff.

> Smalltalk files are not plain text but rather images (or something)

Mostly Smalltalk files are plain text files!

There's a plain text log file with a replayable record of what you've been doing. There's a sources file with the source code. There are plain text file outs and change sets.

There's the VM like the JVM — not a plain text file.

There's the image, a cache of byte code (like Java .class files, Python .pyc files) and application state — not a plain text file.

With a previous Pharo version:

    $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image hello.st

pharo is the VM.

Pharo10-SNAPSHOT-64bit-502addc.image is the image.

hello.st is a plain text file.

    $ cat hello.st
    Stdio stdout 
        nextPutAll: 'hello world'; 
        nextPut: Character lf.!
    SmalltalkImage current snapshot: false andQuit: true!

Yes, you can lock the UI quite easily if you're not careful.