Your example is intentionally and extremely contrived in such a way so as to support your point, and not representative of the real world at all. For instance,

Your example is intentionally and extremely contrived in such a way so as to support your point, and not representative of the real world at all. For instance, if you suddenly ls -l and then want to sort by size instead (yes, I'm aware of -S, and it's irrelevant), then suddenly you have to use far more than just a pipe character. Moreover, the psuedocode is absolutely ridiculous - a more accurate example would be a single function call to list items in a directory, and then another call to sort() with a lambda to pull out the correct field to sort on. In Common Lisp: (sort (ls) :key (lambda (entry) (size entry))) Compare that to your psuedocode snippet. > It's true that it doesn't do everything you want. My point was that it doesn't do anything. It's like function composition in any modern programming language - it's so incredibly trivial that nobody mentions it, because it's both necessary for most operations but also completely insufficient for doing those operations on its own. It's not "glue" in the same way that function composition is not "glue" - it doesn't do any more connection than just enabling things to theoretically exchange data in some way. > But it's truly glue. Maybe according to your own definition, but certainly not in the way that the article (and I) use it, which is "the unglamorous, invisible code that connects two pieces of software, makes sure that data that's in location A reaches location B unscathed (from the datbase to the UI, from the UI to the model, from the model to the backend and so on...)" ...which clearly means that the data is actually transformed into a format that the receiving code can read - which pipe does not do. > I don't think you can call it foolish and be taken seriously. If someone doesn't take me seriously (after I make my point, of course), then that's an indication that their own mind has been blinded by a zealotry for the Unix style, not that my point is invalid. > it was neither the first nor the last system to transfer unstructured data and rely on external programs to interpret them ...which doesn't matter, because it was still a design decision that the Unix architects made, and one of the ones for which Unix is best-known for. > It seems to have paid off too - systems descended from this design are widespread. The idea that popularity implies a good system design is a pretty well-known fallacy. Look at PHP - nearly universally acknowledged to be awfully-designed, and yet extremely popular. Windows, JavaScript, Java, and more - all popular, all poorly-designed. > You might not like paying the tradeoff, but a lot of people find it productive. You can say the same about dynamically-typed programming languages, and weakly-typed programming languages, and even untyped programming languages (Tcl, where everything is a string) - an illusion of productiveness, where you spend much more time down the line debugging mistakes caused by the flaws in your methodology.