Misconceptions about the UNIX Philosophy (2024)
17 points by runxiyu
17 points by runxiyu
The biggest misconception about the UNIX Philosophy™©®, imo, is treating it like a religion instead of a vaguely good idea.
Or a vaguely bad (or at least dated) idea, especially in regards to "do one thing and do it well".
The actual UNIX philosophy is that every user is also a programmer and possibly a sysadmin; overlaps are expected.
I’m not convinced that there is a philosophy, just a post hoc rationalization of shell pipelines. And I’ve got a lot of sunk cost in shell pipelines, but imagine instead a statically typed Smalltslk on top of .NET with all the functionality we depend on in Unix utilities available as libraries. That would be a far more composable environment that bore no resemblance to Unix today. Sadly, what we got is PowerShell, which repeats the tragedy of the Unix shell as farce.
I’m not convinced that there is a philosophy, just a post hoc rationalization of shell pipelines.
I'm not so sure. As I understand it, the shell is the defining feature of UNIX. The ability to "script" the system, rather than compile new programs, makes it very flexible and quick to experiment. Presumably this was especially true back in those days where compilation was slow and systems were still rather batch-oriented.
In current days, building pipelines on the shell is still somewhat more accessible to sysadmins and non-programmers than writing complete programs is. However, the distribution of "technical" and "non-technical" users has changed drastically since the UNIX days, and regular computer users find the shell very daunting and too much like programming, especially since the rise of point-and-click systems. Arguably those type of systems are what made computers more accessible in the first place.
Either way, UNIX is mostly obsolete and your point about having reusable libraries is probably a better fit for today's computer use. But I think we already have that with widely available package repositories (think NPM, PyPi etc).
Composability doesn't have to be between programs, if for example you are building a game or end user program, composability may mean that individual libraries or components of the overall program fit together nicely. A single program can be UNIX-like, if the various individual pieces of its internals fit together well.
IMHO, that seems necessary, but not sufficient. I don't see how merely "fitting together well" makes something particularly UNIX-like, unless it also exposes those seams to the user to reassemble into another configuration to suit their needs.
Maybe the author thought that was implicit in what they were saying, but it doesn't come across that way.
I do believe that well-designed interfaces with strongly typed schemas/protocols are some of the most helpful things for this interpretation of the UNIX philosophy.
well-designed interfaces with strongly typed schemas/protocols
I’m a unix fan, and I think that being a fan entails talking about both the good things and the bad things. And unix has a lot of poorly-designed interfaces: dd? find? make? and absolutely no strongly typed anything wtf.
Could it have been strongly typed back when first written in the 70s? Unix has been in continuous development for well over 50 years, so there's quite a bit of backwards compatibility to keep in mind. As for dd, that might have been an adaptation of a utility from mainframes (it has that vibe). find? Don't know. make? I find it ... okay?
Could it have been strongly typed back when first written in the 70s?
Heh, no, not in the slightest. https://lobste.rs/c/rcxjpz
I have also long thought the fixation on text was misplaced. Personally, I think of text as the "nice debugging interface" and just as we don't run all programs under debuggers, it's ok for binary to be the primary/intended way with a fall back to decoded interactions like tcpdump or xsnoop or etc. You do need some kind of "narrow waist"/agreed upon intermediary/transfer ideas, but it doesn't have to be text, exactly. It may need some kind of "textually possible representation" to be easy to read, but I don't think "bet on text" means the text inside the hex editor UI. ;-)
As another e.g., if you don't have a very diverse distributed system to worry about (the common case for me my own whole life), you can pretty easily forget printing & parsing & even embrace random access not just pipes to do binary data streams & files the way dynamically loaded shared libraries have always been done including a binary-like strongly-typed awk "compiler" in about 50 lines of Nim code (yes, by cheating, but that's kind of the point). (Bulk-translation like dd swab rather than on-the-fly hton-like conversion is also available.) All you need do is anticipate scale which is sometimes self-evident.
Wait what, the folks from Oxide interviewed Johnathan Blow? What a crossover! I follow both "universes" (like many here I guess), such a pleasant discovery. The article linked is 2024, but the interview is from 2020 https://youtu.be/ZkdpLSXUXHY
Back then Jessie Frazelle was still at Oxide and the podcast was called "On the metal" (now "Oxide and Friends")