I don’t think the Unix philosophy of having lots of small tools that do one thing and do it well that you compose together has ever been achieved

Why do you think this might be the case? It's not remotely accurate, which suggests that you must understand it very differently than I do. To some extent, I am curious.

I'll give you a recent example. Which is just from yesterday. I had a use case where some program had a memory leak, which would eventually lead to the system running out. So, I "built a program that would monitor this and kill the process that used the most memory". I don't know how complicated this is in windows and PS, but it took about 2 minutes in Linux, and it very much leverages the Unix philosophy.

Looks something like this:

get_current_available_memory_mb() {
    cat /proc/meminfo | grep MemAvailable | grep -oP '\d*' | xargs printf "%d / 1024  \n" | bc
}

Functionality based on putting together very small pieces that do their things well.

• /proc/meminfo is a file pipe that gives you access to information related to memory usage.
• cat just outputs data from a file or a named pipe, here the latter
• grep lets you filter stuff. First time the relevant line. Then again to strip out the number with a regex.
• xargs does one thing well, and lets you pass that on to another command as arguments, instead of stdin.
• printf formats the output, here to express the numerical operation of dividing the value by 1024 as "[number] / 1024"
• bc evaluates simple mathematical operations expressed in text

Result: 1 file pipe and 5 simple utilities, and you get the relevant data.

The PID of the process using the most memory you can get with something like:

ps aux --sort=-%mem | head -n2 | tail -n1 | awk '{print $2}'

Same sort of breakdown: ps gives you access to process information, and handles sorting by memory usage. head -n2 just keeps the first two lines, but the first one is a header so tail -n1 keeps the second line. awk is used here to only output the second column value. And, you get the relevant data. Also, with simple tools that leverage the Unix philosophy.

You then check if the available memory is below some threshold, and send a kill signal to the process if it does. The Unix way of thinking also stops you from adding the infinite loop in the script. You simply stop at making it do that one thing. That is, 1. check remaining memory. 2. if lower than X, kill PID". Let's call this "foo.sh".

You get the "monitoring" aspect by just calling it with watch. Something like watch -n 2 -- ./foo.sh.

And there you go. Every two seconds, it checks available free memory, and saves my system from freezing up. It took me 10 times longer to write this reply, than to write the initial script.

If memory serves me correctly, PS also supports piping, so I would assume you could do similar things. Would be weird not to, given how powerful it is.

I could give you an endless list of examples. This isn't so much a case of "has ever been achieved", but... a fundamental concept, in use, all the time, by at least a dozen people. A dozen!

Also yesterday, or it might have been Saturday. To give you another example, I scratched different itch by setting up a script that monitors the clipboard for changes, if it changes, and now matches a YouTube URL, it opens that URL in FreeTube. So... with that running, I can copy a YouTube URL, from anywhere, and that program will immediately pop up and play the video. That too, took about 2 minutes to do, and was also built using simple tools that do one thing, and one thing well. If you wanted it to also keep a local copy of that video somewhere, it wouldn't be more effort than the 10 seconds it takes to also send that URL to yt-dlp. One tool, that does that one thing well. Want to also notify you when that download is complete? Just add a line with notify-send "Done with the thing". What about the first example, if you want to get a OS level notification that it killed the process? Just add a line to notify-send, same tool that does that same one thing well.

None of this takes much effort once you get into it, because the basic tools are all the same, and they don't change much. The whole workflow is also extremely iterative. In the first example, you just cat meminfo. Then you read it, and identify the relevant line, so you add grep to filter out that line, and run the command again. It's now a line containing the value, so you add another grep to filter it out the number, and again, run it. "Checks out". So, you pipe that to printf, and you run it. If you fuck something up, no biggie, you just change it and run it again until that little step matches your expectations, and you move on.