• I’ve read this three times now, and I just don’t find this argument very compelling as it stands.

    One thing you learn acutely in functional programming, particularly of the typed kind where you maximize the stated value of composability, is that abstractions are never free. Every abstraction is a tradeoff both for the programmer and the program itself. Lenses, for example, are maximally composable accessors but come with significant cognitive overhead and often have performance implications as well. We shouldn’t simply maximize generality for its own sake, but rather make conscious decisions about the value our abstractions bring vs the cost they incur.

    This is especially true for the author’s example. In the case given, the separation of String->File to allow for String -> [File] has profound implications when paired with operations like head. The author is optimizing on a lexically informed rule (“one step per pipe operator, only modify one step at a time”) and buying a very questionable and fraught form of generality in return.

    To me, the scales don’t seem to balance at all. The stated underlying principle is one of principle maximization rather than software utility. which I think is probably why this doesn’t work for me.


    score 1 · canonical

  • I agree with this post wholeheartedly. the “useless” use of cat is quite useful and I use it all the time. I wrote a whole long comment about it but the gist is simply “if you find the useless use of cat to be useful, use it”


    score 27 · canonical