Alastair M. D. Touw 🍥 @amdt@mastodon.social

Assume this is a work of fiction.

I hate computers (and programming is terrible). 💩

‘A friend of mine had the realization that opening /net/tcp/clone in [#Plan9] and reading the /net/tcp/$number is HATEOAS and I’m fucking reeling’—Daniel Morsing https://nitter.net/DanielMorsing/status/975013193465638918

The other day I wanted a Smalltalk implementation of a YAML parser, but couldn’t find one, and now I’m considering writing one myself. This is a terrible idea: I haven’t written a parser — not even with a parser generator — since I graduated and the spec. is 84 pages… but if I post this it’ll probably satiate my lizard brain and I can get on with my life!

The intersection of Richard M. Stallman fans, and Bill Wurtz fans, is REALLY small.

All of this to say that I have considerably more affinity and longing for the Lisp and Smalltalk machines, where there was no distinction between kernel- and user-space, and the address space wasn’t cordoned-off between processes.

The degree to which our current thinking about how computer systems should be composed is restricted by the (perfectly valid for the time) architectural decisions made for a multi-user time-sharing system for 16-bit minicomputers with a couple of megabytes of memory… is frustrating!

There are few things I care less about than the arguments UNIX fans have about where something should be implemented. It’s of absolutely no interest to me. It’s as interesting as two neighbours arguing over the position of the fence between their houses, or schoolboys playing football and arguing about the distance of their sweaters as impromptu goal posts.

Alacritty, a very recently developed terminal emulator, for years had absolutely no ability to scroll the output because its author believed its implementation should be left to terminal multiplexers, such as ‘screen‘ or ‘tmux’.

There are also non-UNIX examples: the Multics community argued about whether line and text editing features should be implemented by Multics at all, or left to be implemented by manufacturers of video terminals.

This is not a thread about Plan 9; it’s just an example of something I have difficulty with about the UNIX culture: the endless academic jostling about whether something should be implemented, or left as an exercise for the user, and if it is implemented, whether it’s done with core utilities, or as a shell script etc.

If its implementation as a shell script is trivial, then it should be implemented as a shell script… and then added to the standard distribution!

The community offers several solutions to the problem of wanting to recursively copy the contents of one directory to another: the first is to just not do that; the second, to just bind the contents of one directory into another; the third, since it’s apparently trivial — is to implement it yourself as a shell script.

It seems Plan 9’s developers were reticent to implement tree-walking algorithms in the core utilities more than a few times, so they left its practical uses as a problem for the user (or as an intellectual challenge, for some); this is classic UNIX culture (which BSD and GNU thankfully didn’t inherit).

(Plan 9’s ‘cp’ doesn’t support recursing into sub-directories and this often trips up newcomers to the system.)

I recently saw a toot marveling at the usefulness of ‘tar’ in a pipeline to recursively copy the contents of one directory to another in Plan 9.

‘… the unity of the Emacs interface, and the lack of “text entry mode vs. edit mode” and similar implementation artifacts are fundamentally important features, and not to be traded off for any amount of implementation efficiency. Optimizations must be completely transparent and automatic, or they are not optimizations at all, but design tradeoffs.’—Bernard S. Greenberg, Multics Emacs: The History, Design and Implementation. 🏷️ #Emacs https://www.multicians.org/mepap.html