The Unix Executable as a Smalltalk Method [pdf](programmingmadecomplicated.wordpress.com)
programmingmadecomplicated.wordpress.com
The Unix Executable as a Smalltalk Method [pdf]
https://programmingmadecomplicated.wordpress.com/wp-content/uploads/2025/10/onward25-jakubovic.pdf
23 comments
Sounds interesting; I would like to see more OSes built out of passion. Just curious about design choices (I don't mean to come off as aggressive below):
> from basing off of Plan 9 to building a new exokernel in a language like Rust
This seems like a big change. Won't the driver support and infrastructure be even more of a hassle? And why an exokernel in particular?
> using a single-address space design similar to Opal
Why?
I like the emphasis on composability and user control. I think, more and more, people are realizing the necessity to seek out OS designs different than the mainstream offerings'. Can't let Linux be the final stage of OS evolution!
> from basing off of Plan 9 to building a new exokernel in a language like Rust
This seems like a big change. Won't the driver support and infrastructure be even more of a hassle? And why an exokernel in particular?
> using a single-address space design similar to Opal
Why?
I like the emphasis on composability and user control. I think, more and more, people are realizing the necessity to seek out OS designs different than the mainstream offerings'. Can't let Linux be the final stage of OS evolution!
Sounds exciting!
The ICFP/SPLASH papers are now starting to find their way to HN.
This was a HUGE combined programming conference with several competing tracks over 7 days. You can find the program here ^1 (you can often find a link to the abstract or full paper if you click on it)
Streams from the sessions will also show up here^2 (you’ll need to match the day and room and ff to the time it appeared)
^1: https://conf.researchr.org/program/icfp-splash-2025/program-...?
^2: https://youtube.com/playlist?list=PLyrlk8Xaylp5ihrTVeOSaylaB...
This was a HUGE combined programming conference with several competing tracks over 7 days. You can find the program here ^1 (you can often find a link to the abstract or full paper if you click on it)
Streams from the sessions will also show up here^2 (you’ll need to match the day and room and ff to the time it appeared)
^1: https://conf.researchr.org/program/icfp-splash-2025/program-...?
^2: https://youtube.com/playlist?list=PLyrlk8Xaylp5ihrTVeOSaylaB...
I think it worthwhile pointing out Xerox PARC efforts to bring their programming environments to UNIX, as they slowly lost the market they could have had.
"UNIX Needs A True Integrated Environment: .CASE Closed"
http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-4...
Interlisp-D gets ported to UNIX in 1988
https://interlisp.org/history/timeline/
Cedar gets ported into UNIX in 1989
"Experiences creating a portable cedar"
https://dl.acm.org/doi/10.1145/74818.74847
NeXTSTEP and macOS are only thing left from those ideas in modern systems, combing UNIX and Xerox PARC worlds.
While there are some of those ideas influenced Windows, via Objective-C => Java => .NET, and Android is what Inferno/Limbo could have been, it is not quite the same as those early ideas how computing should be like.
"UNIX Needs A True Integrated Environment: .CASE Closed"
http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-4...
Interlisp-D gets ported to UNIX in 1988
https://interlisp.org/history/timeline/
Cedar gets ported into UNIX in 1989
"Experiences creating a portable cedar"
https://dl.acm.org/doi/10.1145/74818.74847
NeXTSTEP and macOS are only thing left from those ideas in modern systems, combing UNIX and Xerox PARC worlds.
While there are some of those ideas influenced Windows, via Objective-C => Java => .NET, and Android is what Inferno/Limbo could have been, it is not quite the same as those early ideas how computing should be like.
Reminds me of the "Liberating the Smalltalk lurking in C and Unix" talk by Stephen Kell: https://www.youtube.com/watch?v=LwicN2u6Dro
Thanks I was looking for that. I've seen a video about that some time ago and couldn't remember the name or the anything.
For those interested here's a link to the actual project:
* https://github.com/stephenrkell/liballocs
For those interested here's a link to the actual project:
* https://github.com/stephenrkell/liballocs
Probably a lot of overlap with the links upthread, but [0] also goes over Unix and Smalltalk (and I only just realized is also by Stephen Kell).
[0] https://dl.acm.org/doi/10.1145/2525528.2525534
[0] https://dl.acm.org/doi/10.1145/2525528.2525534
This quote from Dan Ingalls is also relevant:
"An operating system is a collection of things that don’t fit into a language. There shouldn’t be one."
"An operating system is a collection of things that don’t fit into a language. There shouldn’t be one."
Joel Jakubovic's talk is here: https://youtu.be/gD7ajjCHYbU?t=20378
It includes Q+As from a number of people, including Stephen Kell.
I recall someone, maybe Alan Kay, saying that object oriented programming was a bit of a misnomer. A better description of what they were getting at was message oriented programming, replacing the notion of blocking function calls with message passing. Objects were just a way of grouping state with functions and were less significant.
Yes it was Alan Kay.
https://wiki.c2.com/?AlanKayOnMessaging
Another relevant page on the same site is: https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
Another relevant page on the same site is: https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
Funny, and the persistent memory-image everyone outside the Smalltalk/Lisp community seems to hate, it's your normal filesystem now.
The irony is that anyone using IDEs is using the same idea, as all of them use a virtual filesystem layer to simulate the same capabilities as the image approach.
Not really, because you still recompile and start the program from scratch, rather than modifying the code that executes on the still-existing data structures.
Edit: rather than just naysaying, it occurred to me to reference the notion of Orthogonal Persistence, which the image-based approach provides (not without drawbacks) but IDEs typically don’t. Previous HN discussion: https://news.ycombinator.com/item?id=39615228
Edit: rather than just naysaying, it occurred to me to reference the notion of Orthogonal Persistence, which the image-based approach provides (not without drawbacks) but IDEs typically don’t. Previous HN discussion: https://news.ycombinator.com/item?id=39615228
Kind of, see Cadilac model for Energize C++, born out of Lucid Lisp.
https://dreamsongs.com/Cadillac.html
https://dreamsongs.com/Cadillac.html
Once you cut through all the verbiage, this is just a re-invention of Woosh (https://woosh.sourceforge.net/).
Oh, awesome! I didnt know Woosh got uploaded to SourceForge!
He does go into some ideas about how to implement this approach more efficiently, which seems potentially very important to making it useful.
He does go into some ideas about how to implement this approach more efficiently, which seems potentially very important to making it useful.
Nice Onwards! paper. But to my taste it's a bit slow-paced, taking 10 pages to, as I see it, start getting to the point:
When I implemented this idea in 02002 (in shell scripts) the clumsiest thing was lifetime management of the objects, as Jakubovic anticipates in the paper. I had thought that I put symlinks to the method scripts directly into each object directory, making it a prototype-based OO system, but no, it actually implemented walking a prototype chain, just as Jakubovic's proposed system walks a superclass chain. And, just as Jakubovic did, I passed the receiver's pathname as the first argument to the method executable, passed arguments on the command line, and returned results on stdout. I called my version "shoo"⁴ but it wasn't original to me, inspired by Martin Hinsch's "woosh"⁵:
> shoo makes your filesystem and shell into a prototype-based object-oriented programming environment with dynamic method binding, transparent persistence (but terrible memory management!), multiple inheritance, and local-network distributed objects (if you have NFS, and only the state is distributed --- not the computation).
> Unfortunately, it still doesn't make the shell into a decent general-purpose programming language.
shoo was painfully slow. The `testscript` in the package takes 4.5 seconds on my cellphone in Termux, and all it does is instantiate two rectangular points, two polar points, and three other objects, and call some methods on them. I'm pleased to see that it does at least pass, but it might be reaching 10 or 20 message sends per second.
In shoo, the pathname at which to create the new object was an argument to the new and derive methods, as in Tk. I think something like this is probably a good idea if you want to use this approach for something; otherwise it would be very difficult to clean up. It also makes the shell script quite a bit more readable because you don't have to capture return values so often:
Other code did have to use the rather clumsy bash syntax for capturing output. I didn't attempt to make numbers and strings into objects as Jakubovic wants to; here's the method rectpointclass/r, which calls the x and y accessors:
There are several factual errors in the paper, but I think the only consequential one is the assertion that FUSE makes it possible to implement files as efficiently as Smalltalk objects. It's true that io_uring has made it possible to eliminate the system call context switching overhead from file operations, but even within the kernel, dispatching a user I/O request to a filesystem is at least an order of magnitude slower than a Smalltalk message send on the same hardware, and FUSE adds additional overhead.
Some Smalltalk object memories segregated objects by class, so that all the objects of the same class were contiguous in memory, like an array of structs of the same type. It might be reasonable to put many objects containing the same set of fields into an Apache Arrow file so that they can be read by processes without having to read in the whole file, relying on memory mapping. (Arrow is a language-independent in-memory data format.) Or you could just accept the small overhead of Linux files, which might be 256 bytes of disk and, even without io_uring, only about four 300ns system calls¹ to read their contents: 1.2μs (open, read, read, close). It isn't fast enough to do everything you can do with a Smalltalk system today, but it's fast enough to do everything you could do with a Smalltalk system in the 70s.
As long as you don't try to write it in bash. LuaJIT might be a reasonable alternative, combining easily editable scripts with a reasonable library system and reasonable startup time.
______
¹ http://canonical.org/~kragen/sw/dev3/syscallovh.c
² http://canonical.org/~kragen/sw/dev3/server.s
³ http://canonical.org/~kragen/sw/dev3/forkovh.c
⁴ https://www.mail-archive.com/[email protected]/msg0...
⁵ http://web.archive.org/web/20040409072028/http://wosx30.eco-...
self=$1
tmp1=$(send $self height)
tmp2=$(send $tmp1 / float/3.0)
crossHeight=$(send $tmp2 rounded)
tmp4=$(send int/0 \@ $crossHeight)
tmp5=$(send $self bounds)
send $tmp5 insetBy: $tmp
When I implemented this idea in 02002 (in shell scripts) the clumsiest thing was lifetime management of the objects, as Jakubovic anticipates in the paper. I had thought that I put symlinks to the method scripts directly into each object directory, making it a prototype-based OO system, but no, it actually implemented walking a prototype chain, just as Jakubovic's proposed system walks a superclass chain. And, just as Jakubovic did, I passed the receiver's pathname as the first argument to the method executable, passed arguments on the command line, and returned results on stdout. I called my version "shoo"⁴ but it wasn't original to me, inspired by Martin Hinsch's "woosh"⁵:
> shoo makes your filesystem and shell into a prototype-based object-oriented programming environment with dynamic method binding, transparent persistence (but terrible memory management!), multiple inheritance, and local-network distributed objects (if you have NFS, and only the state is distributed --- not the computation).
> Unfortunately, it still doesn't make the shell into a decent general-purpose programming language.
shoo was painfully slow. The `testscript` in the package takes 4.5 seconds on my cellphone in Termux, and all it does is instantiate two rectangular points, two polar points, and three other objects, and call some methods on them. I'm pleased to see that it does at least pass, but it might be reaching 10 or 20 message sends per second.
In shoo, the pathname at which to create the new object was an argument to the new and derive methods, as in Tk. I think something like this is probably a good idea if you want to use this approach for something; otherwise it would be very difficult to clean up. It also makes the shell script quite a bit more readable because you don't have to capture return values so often:
oo newobj pr
oo basicobject derive thirdobj
oo thirdobj defprop acting "What's my motivation?"
oo thirdobj acting
oo newobj derivefrom thirdobj
oo newobj acting
oo anotherobj die
oo newobj die
Other code did have to use the rather clumsy bash syntax for capturing output. I didn't attempt to make numbers and strings into objects as Jakubovic wants to; here's the method rectpointclass/r, which calls the x and y accessors:
#!/bin/bash -e
# generate radius for a rectangular point.
x="$(oo "$1" x)"
y="$(oo "$1" y)"
echo "e(l($x * $x + $y * $y)/2)" | bc -l
There are several factual errors in the paper, but I think the only consequential one is the assertion that FUSE makes it possible to implement files as efficiently as Smalltalk objects. It's true that io_uring has made it possible to eliminate the system call context switching overhead from file operations, but even within the kernel, dispatching a user I/O request to a filesystem is at least an order of magnitude slower than a Smalltalk message send on the same hardware, and FUSE adds additional overhead.
Some Smalltalk object memories segregated objects by class, so that all the objects of the same class were contiguous in memory, like an array of structs of the same type. It might be reasonable to put many objects containing the same set of fields into an Apache Arrow file so that they can be read by processes without having to read in the whole file, relying on memory mapping. (Arrow is a language-independent in-memory data format.) Or you could just accept the small overhead of Linux files, which might be 256 bytes of disk and, even without io_uring, only about four 300ns system calls¹ to read their contents: 1.2μs (open, read, read, close). It isn't fast enough to do everything you can do with a Smalltalk system today, but it's fast enough to do everything you could do with a Smalltalk system in the 70s.
As long as you don't try to write it in bash. LuaJIT might be a reasonable alternative, combining easily editable scripts with a reasonable library system and reasonable startup time.
______
¹ http://canonical.org/~kragen/sw/dev3/syscallovh.c
² http://canonical.org/~kragen/sw/dev3/server.s
³ http://canonical.org/~kragen/sw/dev3/forkovh.c
⁴ https://www.mail-archive.com/[email protected]/msg0...
⁵ http://web.archive.org/web/20040409072028/http://wosx30.eco-...
[deleted]
During the COVID-19 pandemic I collected my thoughts on my blog (https://mmcthrow-musings.blogspot.com/2020/04/a-proposal-for...) and on a site that I decided to dub MallowOS (https://mallowos.com/), paying homage to Apple's Pink/Taligent project and Google's Fuchsia project.
Unfortunately I haven't made any progress beyond design notes written in paper notebooks; I've got swamped with work (though now I have more free time since becoming a community college professor last year; I have summers off now!). I've also changed my design plans from basing off of Plan 9 to building a new exokernel in a language like Rust, adapting NetBSD's rump kernel for driver support, and using a single-address space design similar to Opal (https://dl.acm.org/doi/10.1145/195792.195795), though this isn't reflected in the MallowOS webpage yet.
Another thought has come to mind: not too long ago there was a discussion here about Etoile (http://etoileos.com/), a project from the late 2000s-early 2010s that attempted to build a GNUstep-based desktop environment. What made Etoile unique is its embrace of the Smalltalk inspirations of Objective-C. Imagine a new project that took Smalltalk inspiration one step further by adapting the ideas of this paper, fully integrating Smalltalk with the Unix framework.