> People seem to have forgotten that when Perl evolved from being a better AWK to the paradigm example of the modern "scripting language", Larry Wall explicitly described this as a rejection of the Unix small-tools philosophy. https://web.archive.org/web/20070204053516/http://www.linux-... ("But Perl was actually much more countercultural than you might think. It was intended to subvert the Unix philosophy. More specifically, it was intended to subvert that part of Unix philosophy that said that every tool should do only one thing and do that one thing well.") https://www.wall.org/~larry/pm.html The fact that getting things done with a Perlesque scripting language is now seen as the height of purist Unix propriety only shows how far gone the original Unix ideal now is. But moving to the scripting-glue model doesn't really get rid of small tools that endeavour to do one thing well, it just reimplements them inside the scripting-language universe as functions/objects, though with a more expressive and less burdensome common language that makes it easier for them to stay small while being correct and effective. The more expressive their shared language, the smaller [the individual tools in] a set of tools can be.
>> Text just isn't a great medium for IPC.
> Yes, in retrospect Unix's determination to know about nothing but binary or plaintext blobs and streams looks like an adolescent rebellion against the (apparently - I haven't used them) clunky record structures of '60s operating systems.
[Extra text] added for clarification (in 2022 actually https://news.ycombinator.com/item?id=31259795 ) and links fixed. Basically, if you want smaller tools you must have a more expressive language—which means (in part) a more structured language—for communication between tools. Though that's not Unix's only design shortcoming: for instance it's also a big problem that even in Plan 9 mount "outputs" only files, not processes.