The problem is not the ability to "do one thing well", but rather that the power means the tool ends up doing a lot of other things ... not so well.

Patch does a good job of patching. There is no reason why it should also have the job of being able to run arbitrary scripts.

FWIW, perl was what convinced me that the previous Unix-y ideal of "do one thing well", was overhyped.

I personally don't interpret "do one thing, and do it well" to mean "do one small thing, and do it well"; the "one thing" could be as big as a programming language, or a display server, or whatever. Perl's "one thing" would be being a scripting language; it should be a scripting language, and it should be the best scripting language it can be. It just shouldn't also do a bunch of other stuff, like also being an RDBMS.

That philosophy could also be applied recursively; Perl should do just one thing; it should be a good scripting language. The Perl JSON module should just do one thing; it should be a good JSON encoder and decoder. That doesn't mean it should be simple; the JSON module should have as much complexity as necessary to make it a good and useful tool.

I do recognize that my interpretation isn't a great _definition_, because you can construe most things to be UNIX-y if you just expand what "one thing" it should be good at enough, but I do think it's useful to keep in mind when designing something.

That said, I have never written Perl (other than a very tiny amount of Perl 6), and don't know exactly what about it convinced you, but I wouldn't mind a discussion about it if you clarify.

The "do one thing, and do it well" is really misleading, the Unix philosophy cannot be distilled down to a single phrase - this phrase only makes sense if you already understand the ideas (also naming it "philosophy" is kinda misleading too because it doesn't expect everything to follow it, only use it as an ideal for program design that you should strive to follow, but not bind yourself over it and ignore it when it makes sense - a good example for this would be something that does a lot of things that in turn allow programs to follow the Unix philosophy better - like an OS kernel).

The main idea behind the "do one thing" is really composability: by doing one thing, your program can be used to provide the functionality for other programs to form applications. Patch uses ed because it needs to edit text and ed provides the text editing functionality, but ed can also be used interactively or from a shell script or by some other program. This is because ed doesn't care how it is called nor where the commands come from. This isn't enabled by its simplicity, but by its design to be composable: it would be a trivial difference in terms of complexity (and indeed there were similar programs in other systems that did exactly that) to ask the user for a filename upon launching it. But that would only make it useful as an interactive program (which is also why the Unix philosophy warns against captive user interfaces).

Ironically, Microsoft's COM and OLE followed that idea better than anything on the graphical side of Unix ever did (except X11 itself, but few programs ever took advantage of it - the best case would be applications meant to be "swallowed" inside docks - docklets - and panels, but those are very task specific). However there is also something to be said about being simple and COM is anything but simple.

So come up with command line switches to restrict behavior when necessary.

>the power means the tool ends up doing a lot of other things ... not so well.

What I find myself wanting over and over is to do things with software that the developers didn't intend. Maybe using a hammer to mash potatoes is a bad idea, but I don't want the hammer company to make it impossible. Not because I want to shoot myself in the foot, but because preventing me from shooting myself in the foot prevents me from doing a lot of other good things.

> Patch does a good job of patching. There is no reason why it should also have the job of being able to run arbitrary scripts.

It (patch) is not 'run[ning] arbitrary scripts' (ignoring the fact that the actual 'diff' output file is itself a 'script' in a broad sense).

Early versions of diff used to output 'ed' command scripts that would instruct 'ed' how to change one file into another file.

Rather than re-implement all of 'ed' inside of patch, patch simply was written to call 'ed' over a pipe and feed it the input "diff" (in 'ed' format) and let 'ed' handle interpreting the 'ed' script. This in and of itself makes sense. All the 'ed' code for interpreting 'ed' scripts is in 'ed', and enhancements to 'ed' automatically become available to patch and anyone else that calls 'ed' without having to keep plural code bases synchronized. Note that some of this usage may very well have been developed before shared libraries appeared, so there would have been no easy way to share the same 'ed' library among plural tools when there were no shared libraries.

It just so happens that one of ed's commands is a command to execute an arbitrary program. So a carefully crafted diff file can instruct ed to run a program of your choosing.

Patch should have the ability to determine what should be patched and where, then hand off the job of doing that to any other UNIX tool.

I'm not sure if I'm reading your comment correctly but i don't think Perl was ever intended to fit the UNIX philosophy. What with TIMTOWTDY being a central tenet.

I thought the acronym ended with an "I", TIMTOWTDI, "there is more than one way to do it".

But I don't know if this is totally anti-unix; there's something more subtle, unix systems try to have a "proper layering" of tools, starting with high-level stuff like compilers and languages, sitting atop utility programs and shell, which ultimately sit on an OS kernel that offers its own similar layering of complexity, with simple and clean primitives at the very bottom (files, sockets, etc).

Working within this ecosystem of OS/libs/tools, you can compose any particular solution in a wide variety of ways, there's usually more than one "right way" to solve a problem. But the pieces you build your solution upon are generally more and more specialized/single-purpose as you move down the stack.

You're right. I don't know how my brain accepted that Y at the end "There's more than one way to do yoga"? lol

Perl was specifically written as a rebellion against the Unix Way: unifying all those little tools into one giant language.