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?
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.
It would be interesting to compare the number of problems caused by buggy tools versus poor integration!