> 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.
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.