Over the decades I’ve seen the praise and critique of the “Unix way”. I don’t remember reading about the aspect I’ll describe below. This might be a banality, and I haven’t invested much thought into it either. I’m just curious to hear your opinions.

At the core of the Unix way is that tools should do just one thing. Users very often need results that can only be achieved after doing several things. With only single-purpose tools at hand, users have to integrate them. In other words, the tool authors delegate integration to the users.

Here’s the idea I want to discuss. In programming languages, integrating various modules to achieve a goal is already a complex task because we often have to handle numerous failure modes and edge cases. In shell scripts this is much worse, since shells are more limited than programming languages. Writing a tool that does only one thing looks like avoiding the most complicated task. Which leads to a conclusion that the Unix way only works well in a rather small fraction of use cases; the majority of cases are better served by different approaches.

What do you think?

  • hendrik@palaver.p3x.de
    link
    fedilink
    English
    arrow-up
    20
    arrow-down
    1
    ·
    3 days ago

    On the other hand a programmer rarely knows exactly what I’m trying to accomplish. Do I want to count the characters in a textfile? Or the words? Do I want to sort the files by size? age? filename? And which of those am I trying to move? What if I want to delete all files older than 30 days which don’t have the word “elephant” in them? I mean sure, you can implement all of that in a very complex program with a very convoluted user interface… Or you do it the Unix way and give me seperate (simple) tools to count, a tool to sort, search text… and a way to connect it to the delete tool.

    • arty@feddit.orgOP
      link
      fedilink
      English
      arrow-up
      3
      arrow-down
      2
      ·
      3 days ago

      Continuing the train of thought from the post: an approach that might serve you better is not a universal program that does everything. It is rather a custom program that does what you need. It very likely will apply reusable code, but in the form of modules instead of programs. It will be much easier to write well than to write a bash script well.

      • hendrik@palaver.p3x.de
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        3 days ago

        I mean that’s basically the same thing, just a different user interface. I think from a technical perspective it doesn’t matter a lot whether we write down the commands as text/words and connect them with “|” symbols or whether we pick them from a long list of symbols and arrange them as puzzle pieces or connect them with pipes or arrows drawn with the mouse.

        • arty@feddit.orgOP
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          2
          ·
          3 days ago

          In my experience, programming languages offer more control than just connecting inputs and outputs, and it’s easier to get right

          • novafunc@discuss.tchncs.de
            link
            fedilink
            arrow-up
            6
            ·
            3 days ago

            And generally should be more efficient too. Bash and this unix-style tool calling was not designed for efficiency. Which is fine for most use cases, but should be avoided for tools you regular use.

            To be more detailed, every time you call a program using bash, your bash program has to fork into two identical processes. Then all that work of forking is wasting as one of the forks then execs to replace itself with the program you called. And that happens with each tool called.

            Using other programs, like Python, can more efficiently exec other programs without the same overhead of forking. And for longer running jobs, Python is much more efficient as it converts itself to bytecode, whereas bash is purely interpreted.

            The main downside of Python is its longer time to start. So for simpler jobs, bash can be better.

            • hendrik@palaver.p3x.de
              link
              fedilink
              English
              arrow-up
              1
              ·
              2 days ago

              Most computer stuff is tradeoffs anyway. I mean we’re looking at different manifestations of “efficiency” here. On the one hand we’re wasting fractions of a milliseconds here and there. On the other hand this might allow us to execute code in parallel, offer modularization. I can combine wildly different programs from different manufacturers, written in different programming languages. I can install new ones and execute them straight away without reloading my shell…

              But I’d argue this doesn’t even matter all that much. We’re talking tiny fractions of a second in most use-cases. The real efficiency is me sitting in front of my computer and saving 10 minutes of time because it’s easy and straightforward to make the computer do the task I want it to do.

              I’m not a big fan of BASH. I do use it. But mostly when it makes sense and it’s the right tool. And I keep forgetting how to do if-else-statements, when to use single or double brackets… It occasionally breaks in weird ways and it generally needs a lot of background knowledge to write good bash scripts. Python is designed with a bit of a different use-case in mind. But it can also be used to write quick scripts to sort files, do some admin stuff and automate things. Oftentimes it’s a good and comfortable tool to use.