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).
(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”
(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour and build the tools and expect to throw some of them out after you’ve finished using them.
It’s not quite the summary presented.
[1] Ah, the joys of finding a physical copy of The Bell System Technical Journal Vol. 57 / PP. 1897-2312 / July-Aug 1976 at a second hand book store for $5.00 about twenty years ago.
The goal of any tool is to “go away”, ie, disappear from thought as the artist/engineer uses the tool to accomplish a greater goal. To the degree the tool doesn’t go away, progress is limited, ultimately halted.
This provides a simple metric to address you question: if you’re spending time debating whether something or not uses the Unix Philosophy, you’re not reaching greater goals. Simply take a look at the allocation of time required to reach a goal.
My money says that as we stack abstraction on top of abstraction, edge cases are requiring us to discuss tools even more than a decade or two ago. This means that wherever we’re headed, it’s not more productivity and creativity.
Looked at through this metric, it’s obvious that the Unix Philosophy isn’t the answer to anything. It’s simply a nice collection of thoughts that help keep us from piling the BS too deep. Once we make it a goal in itself, we end up back to wasting too much time again.
Note: this also implies that the metric here isn’t in the tool itself; it might very well change from coder to coder or from team to team.
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).
Hi @x64x, many thanks for your interesting comment and for pointing out the wrong author attribution!
I am definitely the one who ought to be thanking you, for a very interesting article! These three rules (in this form) are very commonly attributed to Doug McIlroy, it’s just a small piece of trivia.
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:
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).Here’s what Doug McIlroy actually wrote [1]:
It’s not quite the summary presented.
[1] Ah, the joys of finding a physical copy of The Bell System Technical Journal Vol. 57 / PP. 1897-2312 / July-Aug 1976 at a second hand book store for $5.00 about twenty years ago.
The goal of any tool is to “go away”, ie, disappear from thought as the artist/engineer uses the tool to accomplish a greater goal. To the degree the tool doesn’t go away, progress is limited, ultimately halted.
This provides a simple metric to address you question: if you’re spending time debating whether something or not uses the Unix Philosophy, you’re not reaching greater goals. Simply take a look at the allocation of time required to reach a goal.
My money says that as we stack abstraction on top of abstraction, edge cases are requiring us to discuss tools even more than a decade or two ago. This means that wherever we’re headed, it’s not more productivity and creativity.
Looked at through this metric, it’s obvious that the Unix Philosophy isn’t the answer to anything. It’s simply a nice collection of thoughts that help keep us from piling the BS too deep. Once we make it a goal in itself, we end up back to wasting too much time again.
Note: this also implies that the metric here isn’t in the tool itself; it might very well change from coder to coder or from team to team.
Hi @x64x, many thanks for your interesting comment and for pointing out the wrong author attribution!
I am definitely the one who ought to be thanking you, for a very interesting article! These three rules (in this form) are very commonly attributed to Doug McIlroy, it’s just a small piece of trivia.
Very glad you liked the article, many thanks again!