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.

That old "rm -rf ./$datadir", indeed. I used "shellcheck" for years to help catch the simple stuff.. Back to the topic at hand: Ultimately we have personal goals, and we cannot rely on the author's of other software to know and implement everything we want. Especially when it comes to UIs, it's often a take it or leave it affair.

In this respect, AI software development has been a boon. I'm increasingly creating software for myself in highly performant type-safe languages, using native APIs.. If it's more than a simple script (but also not too complex), modern LLMs are going to do a decent job, faster than I could do it (whereas before I often wouldn't have started, due to limited time). I can mod an existing app that's almost good enough, in order to scratch a personal itch. Or reimplement it from scratch in my preferred form. Small composable apps, tools, and libraries are perfect for this. And most importantly, I don't have to slop up the Internet with my overly opinionated but perfect for me projects. 😉

Okay. Build a weird farm use only modified v10 excursion with half the body removed and a gooseneck receiver welded on.

If you find it too limiting to tape together the standard utilities then do what your intro to programming class did when you learned c and write your own utilities and libraries, zip them up and store them on a cheap vps you can remember the ip or fqdn of and yank them down onto whatever system you happen to be on, pardon the turn of phrase, like a normal person.

The reason a particular style of pressure fitting is mandated by law to be used for hydraulic connections between cabs and trailers isn’t because it’s the most versatile, repairable or even most secure type but because its manual of operation is simple, straightforward and very importantly: excludes off label or dangerous uses.

An alternative to the standard utilities or Unix way is something you want because you think it will be easier and faster and more versatile. It might be that way for you. Combination wrenches tend to have the sizes and shapes they do to accommodate working around the spaces their size of fitting tends to be in and because the wrench snapping in half when you try to operate it with a breaker bar is the tools way of telling you to begin destructive removal of the fastener instead of continuing to pour pb blaster into it.

I like tools to be separated enough that I can do scripted/CLI calls with them through standard interfaces (as opposed to being a GUI/TUI monolith). All sorts of stuff can be done when tools output structured data like JSON that's easy to parse and manipulate, or being able to interact with DBus APIs or services in other ways.

What I don't like is when core tools try to be "smart" and reimplement things that other tools already do and end up making them more difficult to work with. Like package management, we already have Nix, Mise, and a billion other package managers, we don't need another one. And turning the compiler into a package manager (cough Typst, .NET) is just stupid. Also programs editing their own configuration files is annoying as well, I can edit them myself and I don't want them touching my edits, and if other people don't want to do that then maybe a custom interface could be put in a UI/add-on of some sort that's not part of the core tooling.

Also web browsers and web applications are close to bottom of the barrel in terms of scriptability. The stuff the Nix ecosystem had to do to make Firefox configurable is nightmarish, and Electron is an overall mess. Although with everyone wanting to make the programs work with AI agents now, maybe this will improve.

I'm confused what you're trying to say here. It sounds like you are trying to say that unix philosophy fails to address the difficulty of actually composing and integrating the simple primitives provided by GNU/Linux. But you could say that for any programming language.

Unless you are saying that the shell should have intermediate tools that are more specialized than the primitives. Like libraries or frameworks built on shell primitives. But I think for that sort of complexity, shell scripts are too slow and counterintuitive, and you should just use a proper programming language, like all the other complex specialized cli tools in the Linux ecosystem (nmcli, systemd, etc).

I see shell primitives as relics of the past, and I treat them like you might treat the buttons on a GUI. There's a button for copying items called cp, a button for moving items called mv, etc. I rarely compose these tools into complex scripts, and I almost never write bash scripts longer than like 10 lines. For any sort of complexity I use Python or Go.