This is a very good article. It seems to be part of the horrendously expensive book "Reflections on Programming Systems - Historical and Philosophical Aspects"
Rochus•6mo ago
I can confirm that the referenced article is chapter 6 in De Mol's and Primiero's book, which from my humble point of view is a typical Springer book, far a way in an ivory tower.
May I ask in what respect you find the article/chapter "very good"?
I rather think the author makes a fundamental category error (by comparing a complete operating system with kernel, system calls, process management, file systems, and userland utilities, with a programming language, runtime environment, and object library). Also the assumptions about Unix are wrong; Unix - in it's most incarnations - has a monolithic kernel architecture, a fixed system call interface, a rigid separation between kernel and user space, and (originally) static linking as the primary model. The "composable" aspects Kell emphasizes (pipes, small tools) exist at the userland level, not in the fundamental OS architecture. Further, Unix shared objects (.so files) and dynamic loading mechanisms predate widespread Smalltalk influence; the System V and BSD implementations of dynamic linking were driven by practical memory constraints, not Smalltalk inspiration. And every operating system is a "live system that can be modified while running" to some degree. The chapter reads more like an exercise in pattern matching than serious technical analysis. While academic exploration of conceptual relationships between systems can be valuable, it requires much more rigorous attention to technical details and historical accuracy than Kell provides.
igouy•6mo ago
> Also the assumptions about Unix are wrong; Unix - in it's most incarnations …
Perhaps the author has chosen to ignore "most incarnations" and instead select what fits his story:
"In a traditional (pre-commercialisation) Unix system …" page 4
"When I write of “Unix” or “Smalltalk” in what follows, it will be important to distinguish their early, idealised conceptions from their later evolved forms …" page 6
Rochus•6mo ago
Not even the "traditional (pre-commercialisation) Unix system" fits his story.
igouy•6mo ago
Free yourself from the chains of modernist narrative!
Rochus•6mo ago
God Speed!
rbanffy•6mo ago
> I rather think the author makes a fundamental category error (by comparing a complete operating system with kernel, system calls, process management, file systems, and userland utilities, with a programming language, runtime environment, and object library)
It compares the whole stack, from kernel to the user environment. You can run Smalltalk on bare metal, if you want. The separation between OS and the user environment is entirely an architectural decision. IMHO, Unix got it right, while ST and Plan 9 are too tied to their UIs.
> And every operating system is a "live system that can be modified while running" to some degree.
That's not the case at all with Unix and Plan 9 - you can't change the semantics of what a file is without recompiling the filesystem module and forcing a reload.
igouy•6mo ago
Was there something specific that prompted you to say "a very good article"? (Just curious to know what appealed to you.)
Rochus•6mo ago
> 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 with isolated processes and memory separation.
> you can't change the semantics of what a file is without recompiling the filesystem module and forcing a reload
Linux e.g. supports kernel modules which are loadable/replacable at runtime. And if you include the userland in the comparison (as the article does) there is nothing static at all. You can even run the Smalltalk VM (or any other dynamic language) in a Unix userland and have exactly the same modifiability as the article claims for Smalltalk. And a similar effect as claimed in the article can actually be achieved if you compile, run, modify and the run again a C program.
rbanffy•6mo ago
> which implements all madatory primitives (i.e. system calls)
Essentially, it's a collection of device drivers.
> I implemented some tools with which this can be easily studied
Really cool. I'll check it out.
> You can even run the Smalltalk VM (or any other dynamic language) in a Unix userland and have exactly the same modifiability
That's kind of cheating. All the dynamic behavior is on the Smalltalk side, and nothing of it is on the Linux side. Apart from loadable modules, Linux doesn't change behavior at runtime (IIRC, you can't swap process schedulers after startup).
Rochus•6mo ago
> Essentially, it's a collection of device drivers.
Plus memory management, interrupt handling, and some other stuff, everything you would expect from a single-tasking kernel.
> and nothing of it is on the Linux side
You likely mean the kernel. There is more to Linux/Unix than just the kernel. You can even have your dynamically modifiable scheduler in the userland if you want. And for the (few) people who really think full dynamic modifiability is a relevant requirement, there are also some other technologies which offer similar flexibility as Smalltalk, or somewhere between (as e.g. the Gnome Window manager with GTK operated via a scripting language, or Stump, Sawfish, Qtile, etc.). The kernel which runs below Smalltalk (or the Smalltalk interpreter, i.e. the thing which runs the Smalltalk bytecode and manages object memory) neither "change behaviour at runtime". So if we do the correct comparision, there is not much difference when it comes to runtime modifiability.
igouy•6mo ago
> the thing which runs the Smalltalk bytecode
VM ?
"There are about one hundred primitive methods that the Smalltalk-80 virtual machine knows how to perform."
Rochus•6mo ago
The VM includes a bytecode interpreter and some other functions; its implementation cannot be changed during runtime.
rbanffy•6mo ago
Rochus•6mo ago
May I ask in what respect you find the article/chapter "very good"?
I rather think the author makes a fundamental category error (by comparing a complete operating system with kernel, system calls, process management, file systems, and userland utilities, with a programming language, runtime environment, and object library). Also the assumptions about Unix are wrong; Unix - in it's most incarnations - has a monolithic kernel architecture, a fixed system call interface, a rigid separation between kernel and user space, and (originally) static linking as the primary model. The "composable" aspects Kell emphasizes (pipes, small tools) exist at the userland level, not in the fundamental OS architecture. Further, Unix shared objects (.so files) and dynamic loading mechanisms predate widespread Smalltalk influence; the System V and BSD implementations of dynamic linking were driven by practical memory constraints, not Smalltalk inspiration. And every operating system is a "live system that can be modified while running" to some degree. The chapter reads more like an exercise in pattern matching than serious technical analysis. While academic exploration of conceptual relationships between systems can be valuable, it requires much more rigorous attention to technical details and historical accuracy than Kell provides.
igouy•6mo ago
Perhaps the author has chosen to ignore "most incarnations" and instead select what fits his story:
"In a traditional (pre-commercialisation) Unix system …" page 4
"When I write of “Unix” or “Smalltalk” in what follows, it will be important to distinguish their early, idealised conceptions from their later evolved forms …" page 6
Rochus•6mo ago
igouy•6mo ago
Rochus•6mo ago
rbanffy•6mo ago
It compares the whole stack, from kernel to the user environment. You can run Smalltalk on bare metal, if you want. The separation between OS and the user environment is entirely an architectural decision. IMHO, Unix got it right, while ST and Plan 9 are too tied to their UIs.
> And every operating system is a "live system that can be modified while running" to some degree.
That's not the case at all with Unix and Plan 9 - you can't change the semantics of what a file is without recompiling the filesystem module and forcing a reload.
igouy•6mo ago
Rochus•6mo ago
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 with isolated processes and memory separation.
I implemented some tools with which this can be easily studied (https://github.com/rochus-keller/Smalltalk/).
> you can't change the semantics of what a file is without recompiling the filesystem module and forcing a reload
Linux e.g. supports kernel modules which are loadable/replacable at runtime. And if you include the userland in the comparison (as the article does) there is nothing static at all. You can even run the Smalltalk VM (or any other dynamic language) in a Unix userland and have exactly the same modifiability as the article claims for Smalltalk. And a similar effect as claimed in the article can actually be achieved if you compile, run, modify and the run again a C program.
rbanffy•6mo ago
Essentially, it's a collection of device drivers.
> I implemented some tools with which this can be easily studied
Really cool. I'll check it out.
> You can even run the Smalltalk VM (or any other dynamic language) in a Unix userland and have exactly the same modifiability
That's kind of cheating. All the dynamic behavior is on the Smalltalk side, and nothing of it is on the Linux side. Apart from loadable modules, Linux doesn't change behavior at runtime (IIRC, you can't swap process schedulers after startup).
Rochus•6mo ago
Plus memory management, interrupt handling, and some other stuff, everything you would expect from a single-tasking kernel.
> and nothing of it is on the Linux side
You likely mean the kernel. There is more to Linux/Unix than just the kernel. You can even have your dynamically modifiable scheduler in the userland if you want. And for the (few) people who really think full dynamic modifiability is a relevant requirement, there are also some other technologies which offer similar flexibility as Smalltalk, or somewhere between (as e.g. the Gnome Window manager with GTK operated via a scripting language, or Stump, Sawfish, Qtile, etc.). The kernel which runs below Smalltalk (or the Smalltalk interpreter, i.e. the thing which runs the Smalltalk bytecode and manages object memory) neither "change behaviour at runtime". So if we do the correct comparision, there is not much difference when it comes to runtime modifiability.
igouy•6mo ago
VM ?
"There are about one hundred primitive methods that the Smalltalk-80 virtual machine knows how to perform."
Rochus•6mo ago