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?

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.

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.

I think the Unix way is a great ideal if you develop composable cli tools, functions or libraries. In each its easier to reason and recombine a thing, that does one specific thing. More complex user problems are then solved by combining multiple simpler components. Lots of modern graphical user interfaces neither think about what the user might want to do, just offering everything, nor prescribe a specific workflow, which just leaves users that have a only a vague idea of what they want to do or a porgram could do, confused.

Being more unixy would be great for mobile apps as well. iOS for example has these app shortcuts which expose functionality of an app to be combined with other apps featuers. I think once siri AI takes hold this could be done. I think, however, the monetization realities of most software will always pressure them to do lots of things and lock the user in.

I think a big portion of the unix philosophy is to be easy for development. Not for consumers or customers.

The idea is that it will be easier for developers more complex software and flexible software if the pieces they are working with are well defined.

Unix is dead. Everyone ships RESTful services + web UI. Underlying platform doesn't make a difference. You could ship it on Windows server and no one would notice.

The Unix way isn’t for people who can’t integrate those tools.

Ever been in the drivers seat of an 18 wheeler? Even just getting into one requires more physical exertion than getting into your car. When you’re up there you have a million gauges and controls meant to provide the operator the tools they need for any situation they might encounter and to interface with a galaxy of stuff that can be hooked up to the back. You need a special license which encapsulates this different paradigm of use, operating a gigantic vehicle under much different and more variable conditions than the everyday driver (in addition to approaching normal road conditions and functions like turning left with a different outlook and awareness).

It’s why I often tell people not to switch to Linux. It’s not for them.

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.

The programmers and ops would probably notice because it now takes ten times the effort to automate stuff and customize things for their clients. I mean there is a reason why Linux is the market leader for any kind of serious behind-the-scenes computer stuff. But yeah, there's enough abstraction layers in-between. The end-users would probably get pretty much the same service. Maybe at a slightly different price point. And it sometimes has an effect on IT infrastructure at work. You'd either get a more traditional workspace or Office365 and cloud only.

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

Well, my post describes the experience of a developer using these tools. "User" here is supposed to mean the person who combines tools to build a more complex piece of software.

Even if so, discussing dead things could be interesting as well 🦖️

In one way it is a simpler task to fix a single tool, than update a bunch of complex tools that suffer a problem.

BUT this was before the GIT method of pulling changes into a main branch, so maybe nowadays it doesn't matter as much as their is much less effort updating a bunch of tools for a problem, than manually editing and recompiling.

Srill when we talk to users about our software use we alsways recommend using as much out of the box functions to get done what you need, rather than coding new tools for the Open API. Because a software update (should) fix all your workflow and automation that you have leveraged, rather than recoding dozens of apo addons.

I’ve been professionally developing software for two decades. I can integrate those tools. Still, I find it unnecessarily more difficult than integrating programming language modules. And adjusting my solution to use ready-made, well-integrated complex software is significantly easier, all while being more stable.

More complex user problems are then solved by combining multiple simpler components.

What I am trying to say is that this solution is very likely to be poor, not taking into account various failures and edge cases.

It would be interesting to compare the number of problems caused by buggy tools versus poor integration!

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.

The UNIX philosophy does look like "do one thing and do it well", but it's really a means of working in such a way that one doesn't introduce scope creep to a point of Drupal.