From A Scheme Shell, by Olin Shivers:

Shell programming terrifies me. There is something about writing a simple shell script that is just much, much more unpleasant than writing a simple C program, or a simple CommonLisp program, or a simple Mips assembler program. Is it trying to remember what the rules are for all the different quotes? Is it having to look up the multi-phased interaction between filename expansion, shell variables, quotation, backslashes and alias expansion? Maybe it’s having to subsequently look up which of the twenty or thirty flags I need for my grep, sed, and awk invocations. Maybe it just gets on my nerves that I have to run two complete programs simply to count the number of files in a directory (ls | wc -l), which seems like several orders of magnitude more cycles than was really needed.

I liked the example in the article, but we can also use it to show the shortcomings of Unix philosophy. Suppose we wanted to roll a 10-million-sided die (I.E., pick an integer between 1 and 10000000). Here’s what that looks like in terms of computing efficiency.

$ time ( seq 1 10000000 | shuf | head -n1 )
3574362
real	0m6.966s
user	0m6.423s
sys	0m1.277s

I ran that on my Raspberry Pi because it was a good demonstration. It’s faster on x86 systems: 2.5 seconds on a 2012-era AMD CPU, and 1.4 seconds on an Epyc Rome system from 2020.

If we wanted to roll a 2**64-sided die, forget about it.

In practice, what you do in Unix philosophy is write a C program called randrange or similar, adding a new verb to your language.

Another point: one thing that makes Unix philosophy attractive is the compositionality. Compositionality is what some of us love about Forth (I’m an ex-Forther). The difficulty with both is “noise” that obscures solutions to problems. In Forth, the noise is stack juggling. In Unix, it is all the text tool invocations that massage streams of data.

Somewhat tangential: one of the things that many great historical institutions and/or schools of philosophy have in common is that their decline is linked significantly to a point at which new developments stop happening, and every new piece of work is judged not so much by its value, but by how much it conforms to the norms of said philosophy. At that point, a community stops being “productive” in terms of development – it stops advancing things, it just rummages on the old ones until, finally, there comes a generation that simply doesn’t embrace the rummaging anymore, and all is forgotten.

There’s been a pretty “deep” undercurrent that seeks to bring the “old” Unix philosophy to light again for many years now (suckless is a famous, but somewhat recent phenomenon). Frankly, I don’t know what to read into it – is this a truly “productive” re-exploration of the old philosophy, as (what we now call) neoplatonism was to platonism, or is it more akin to the dry scholastic treaties of late scholastic philosophy, produced by aging monks who didn’t get the memo on the Renaissance?

Many years ago (cca. 2011?) when I went down the suckless rabbit hole, I thought it was more like the latter. But in a pretty interesting twist of fate, the decline of the other major platforms in terms of adequacy for professional use is starting to make it look more like the former. Back in 2008 or whatever I really didn’t understand why anyone would ever want to use something like dwm, but after a few years of Gnome 3 and Windows 8, ratpoison looked really good, and I used it for many years.

By the way – another common trait of these “inflexion” points is that, at some point, founding figures take quasi-mythical proportions and it’s no longer clear who said what :). For example, the article makes this claim:

Douglas McIlroy summarized the Unix philosophy as follows:

• Write programs that do one thing and do it well.
• Write programs to work together.
• Write programs to handle text streams, because that is a universal interface.

but this famous form of the summary is not McIlroy’s (whose original formulation, from the famous technical note at Bell Labs, had 4 rules, not 3) but much more recent, it’s the version that Peter Salus gives in his Quarter Century of Unix (at which point, one might argue, pretty much every commercially-successful Unix had departed significantly from this philosophy).

(Edit: why this tangent: another common trait of these decline phases is that a lot of talk seems to devolve into doctrinary discussion after the “point of no return”. While McIlroy, Ritchie and Thompson obviously shared a lot of common ideas about how one should write programs, it’s unlikely that they ever sat at the table and seriously discussed whether something breaks the Unix philosophy or not, the way people discussed systemd 40 years later. To the people who invented Unix, and wrote much of the first generations of Unix programs, what we now call the Unix philosophy is just how you wrote “proper” programs – the formal rules (and the ability to judge by how programs adhere to them, rather than how efficient they are at what they’re supposed to do) came much later. The same goes here – as someone else has pointed out, “the Unix philosophy” might as well suggest cat-ing from /dev/random, but if you approach this problem from the mindframe of PDP-11 era computing – which overlaps with the Unix philosophy to the point where it’s often hard to say where the Unix philosophy ends and where 1970s computing limits begin – you get the author’s inefficient example).

You can get rid of head -n1 at the end of the pipe by using seq 1 6 | shuf -n1.

Alternative:

% env LC_ALL=C tr -c -d '123456' < /dev/random | head -c 1