[HN Gopher] The Unix Executable as a Smalltalk Method [pdf]
___________________________________________________________________
The Unix Executable as a Smalltalk Method [pdf]
Author : pcfwik
Score : 133 points
Date : 2025-10-18 01:03 UTC (21 hours ago)
(HTM) web link (programmingmadecomplicated.wordpress.com)
(TXT) w3m dump (programmingmadecomplicated.wordpress.com)
| chris_armstrong wrote:
| 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...
| linguae wrote:
| I had a chance to skim over the paper, and I'm very inspired; I'm
| looking forward to reading it in depth and considering its
| lessons while working on my side project. For about a decade,
| I've been dreaming about building a modern operating system that
| is highly malleable and encourages component-based software
| design, and I've collected many thoughts and done a lot of
| reading. I've been inspired by many projects, including the
| Smalltalk-80 environment, Lisp machine environments (especially
| Symbolics Genera), various 1990s Apple projects (Dylan, the
| Bauhaus operating system designed for the Newton and written in
| Lisp, OpenDoc), Plan 9, Alan Kay's Viewpoints Research
| Institute's work on STEPS
| (https://news.ycombinator.com/item?id=11686325), and Stephen
| Kell's work on exploring the connections between Unix, Plan 9,
| and Smalltalk.
|
| 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.
| kragen wrote:
| Sounds exciting!
| kragen wrote:
| 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:
| 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
|
| The rest of the paper seems to be about how to make that, or its
| moral equivalent, not just work but work efficiently.
|
| 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"4 but it wasn't original to me, inspired by Martin Hinsch's
| "woosh"5:
|
| > _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
|
| As in Self, adding a property to an object (such as `acting`)
| adds corresponding getters and setters. The `die` method was one
| I defined in basicobject to rm -rf the receiver, due to the lack
| of any GC.
|
| 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
|
| Jakubovic mentions that creating a million Unix processes will
| cause "bad things to happen" but even on my laptop creating and
| destroying a million processes only takes about a minute
| (httpdito2 can serve 20000 hits per second, creating all the
| children from a single core; C programs are much slower3, about
| 7000 fork/exit/waits per second, presumably because they map more
| pages) and I think you could do it in a second with AWS Lambda.
| Possibly you don't want them all to exist at once, but of course
| the original Smalltalk systems couldn't do that either--their
| object references were only 16 bits, so 65536 objects was the
| theoretical max, and they ran on machines without enough RAM for
| even that much.
|
| 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 calls1 to read their contents: 1.2ms (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.
|
| ______
|
| 1 http://canonical.org/~kragen/sw/dev3/syscallovh.c
|
| 2 http://canonical.org/~kragen/sw/dev3/server.s
|
| 3 http://canonical.org/~kragen/sw/dev3/forkovh.c
|
| 4 https://www.mail-archive.com/kragen-hacks@canonical.org/msg0...
|
| 5 http://web.archive.org/web/20040409072028/http://wosx30.eco-...
| stevefolta wrote:
| Once you cut through all the verbiage, this is just a re-
| invention of Woosh (https://woosh.sourceforge.net/).
| kragen wrote:
| 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.
| pjmlp wrote:
| 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.
| Flow wrote:
| Funny, and the persistent memory-image everyone outside the
| Smalltalk/Lisp community seems to hate, it's your normal
| filesystem now.
| pjmlp wrote:
| 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.
| shwaj wrote:
| 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
| pjmlp wrote:
| Kind of, see Cadilac model for Energize C++, born out of
| Lucid Lisp.
|
| https://dreamsongs.com/Cadillac.html
| sph wrote:
| Reminds me of the "Liberating the Smalltalk lurking in C and
| Unix" talk by Stephen Kell:
| https://www.youtube.com/watch?v=LwicN2u6Dro
| bobajeff wrote:
| 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
| api wrote:
| 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.
| shwaj wrote:
| Yes it was Alan Kay. https://wiki.c2.com/?AlanKayOnMessaging
|
| Another relevant page on the same site is:
| https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
___________________________________________________________________
(page generated 2025-10-18 23:01 UTC)