1. 44
  1.  

  2. 19

    I personally quite disagree with the message in this article. The everything as a file view, parseable text as inter-command communication, and focus on “do one thing, but do it well” are strong design principls that still hold true, and I think contribute to the beauty of Unix. I find it particularly interesting that new tools are constantly coming in, like fzf, ranger, neovim or fish, which all improve the user experience while embracing these tried and true principles.

    1. 15

      I mostly agree with you, though I do think the article brings up some meaningful points. People who work with UNIX-like systems are used to dealing with a lot of its quirks and flaws (signals, tar, sh). Some of these decisions had sound reasons to exist when they were first conceived, but nowadays they are mostly a relic of the past that plague modern devices.

      The article does make a large jump from discussing quirks of UNIX, to bashing key UNIX concepts like command piping, without giving any actual examples as to how the latter is harmful. This degrades the message the author is trying to convey a little bit, but I still do think many of the examples that are provided still hold up today as being clunky and difficult to use. All in all, it seems reasonable to bash UNIX’s legacy without dismissing the UNIX philosophy as a whole.

      1. 2

        I suspect the majority of the argument for and against Unix is actually the same thing: it’s old.

        I have a question that I don’t have the knowledge/experience to answer myself, but have been wondering for the longest time:

        What would C look like, if it were designed today instead of the 1970s?

        Or to rephrase it (and possibly put C on a pedestal), suppose we created a language from first principles that mandated 1) a simple language that prioritizes explicitness over intelligent compiler magic, and 2) performance over safety, portability/etc?

        For instance, “the call stack” makes far more sense in a single-core world than in an 8-core world. Actually, I probably shouldn’t assume that C invented the call stack; maybe that’s inherited too.

        Either way, I think with today’s CPU pipeline parallelism, the semicolon wouldn’t define orderedness (so a = 2; a++; a*=2; could increment and double junk data before a is set to 2) and there would need to be a second symbol to actually say what is explicitly ordered. Or maybe you’d use {} for that? I haven’t properly thought about it to be honest.

        But, no way would instructions level parallelism be left up to the compiler to “intelligently” determine.

        That’s just one example. I’m sure a lot of other stuff would change too.

        1. 1

          The example you gave with C makes me think about functional programming and other declarative programming paradigms, where programming is done by describing the desired behavior, without side effects that mutate the program’s state. I would imagine that if C were invented today, it would lean more in that direction, though it’s difficult to imagine how that would look in the context of a systems programming language like C, which is intended to give programmers direct access to low-level details. This would also diminish the explicitness of the language, which is against one of the principles you brought up. I’ve never really thought about that, but that’s incredibly interesting!

          If we’re willing to sacrifice portability, a CPU instruction set designed from the ground up to work in ways compatible with this non-existent language may make things a bit simpler, though once again I’m not really sure what that would entail.

          Alternatively, maybe the language would just require that the programmer explicitly indicate which parts of the code can be run in parallel, and which branches of code depend on which other branches of code. That’s also a really interesting idea.

    2. 15

      Programmers: only by having fancy static type systems can a program possibly be correct.

      Also programmers: the only valid design for a programmer tool is to input any stream of bytes and output any stream of bytes without any metadata.

      1. 12

        I agree that MSDOS doesn’t get enough credit for its pragmatism. And that that 4shell thing looks pretty cool for its time, or even that some ergonomy took a bit too long to arrive to Unix terminals.

        But a few remarks:

        1. Unix terminals and bash are not the same thing. Other shells exist and even things like midnight commander. If anything bash has been considered obsolete for a decade or two by users of fish, zsh, and probably others.
        2. A bit exaherated. By the early 2000s all major distros displayed manpages with formatting and paged by less by default with on screen keybind help.
        3. The author clearly underestimates the versatility and practicality of pipes. Buffering alone is something most people wouldn’t know how to implement anyways. I’ve trwon larger than memory files at pipes regularly for the last couple of decades with zero worries. Pipes handle buffering for me while retaining each ommand isolation. I don’t think people is aware of how big of a deal this is.

        Roughly 50% of the software I work with could be replaced by a Unix one line pipeline. Most of the times with performance improvements. I have done it a few times, but usually co-workers get defensive of their bloated piece of software.

        1. 11

          Man I miss this blog.

          1. 10

            Yes, having a small tool for a specific job sometimes works, but it just as often doesn’t. (“Those days are dead and gone and the eulogy was delivered by Perl,” Rob Pike, 2004.)

            What Perl demonstrated was that:

            a) There can be other environments of tool usage.

            b) Those environments can interlock pretty gracefully with unix.

            Anyhow, there are bits of my technical aesthetic that’ll happily be grounded in the 1970s ‘til I die, I imagine. There are other things I deeply miss from the late-80s – early-2000s profusion of desktop environments and GUI paradigms and network clients - places where it really feels like we’ve regressed dramatically, where I’ve been forced to retreat into the relative surety of terminal and text file…

            1. 8

              The value of being able to compose simple commands with pipes is amazing. One of the big drawbacks to non-Unix programs is that they’re often (but not always; see Emacs) difficult or impossible to use in ways their authors never imagined.

              An example demonstrating the value of the Unix design aesthetic works in 2021: Bash-my-AWS:

              $ stacks | grep postgres | stack-delete
              You are about to delete the following stacks:
              postgres01
              postgres02
              Are you sure you want to continue? y
              
              1. 14

                Except it’s now the Unix-y systems that are lagging behind on “things you never imagined” – Powershell has the ability to compose together commands with piping functionality, for example, but supports far richer structures passing through the pipes than Unix’s “bag of opaque bytes you hope you can decode as text on the other end”.

                And having a bit too much experience of Unix’s approach to “text” as a concept, honestly I think the idea that pipes are only “text” is actively holding back our ability to design and build a new generation of useful command-line interfaces and tools.

                1. 5

                  Yeah PowerShell looks great. I was leaving the Windows ecosystem just as it was getting started, but it looked like potentially the next evolution of pipelines (piping objects, not text).

                  Looks like it might be worth using on *NIX too:

                  https://code.joejag.com/2020/a-month-with-powershell.html

                  1. 3

                    Yep - a really simple example of this is colorized output in shell scripts. It’s way harder than it needs to be to do text processing that maintains colorized output correctly.

                    1. 4

                      Or the sheer number of times some tool has slightly re-worded some output, or even – horror! – added a new line of information and gotten bug reports about “you broke my pipeline”. Unix-y pipes also have the side effect, and not necessarily a desirable side effect, of making the exact formatting of your output text part of your API contract.

                      1. 2

                        Which, to be fair, is also a property of pipelines in Powershell. But being type-based rather than text-based it’s far easier to reason about (IMO).

                      2. 2

                        The history of this is actually pretty interesting.

                        https://en.m.wikipedia.org/wiki/ANSI_escape_code