logoalt Hacker News

StilesCrisisyesterday at 2:31 PM2 repliesview on HN

This argument is just based on "I wish the things I need to do were baked into the language." It's nice when that happens, but once programs get sufficiently large and complex, it stops mattering--you're dealing with domain-specific concepts that have zero built-in helpers and you're just building everything yourself regardless.


Replies

zahlmantoday at 9:49 AM

Maybe, but there are a couple of different kinds of "things" here: the actual primitive operations, and the techniques available for combining and coordinating them. For example, the `sort` program can only be told to sort based on certain specific analyses of the line contents (like extracting a certain "field" and converting that string to integer); it can't be supplied with a higher-order function. While things like `tee` exist, it isn't really practical to treat part of the pipeline as a reusable abstraction, except perhaps by writing a file (which leads to the author's approach with temporary files and `join`). And of course you're stuck with constant serialization and deserialization between processes.

https://news.ycombinator.com/item?id=49600275 is a great illustration of how to use Bash's "means of combination" more effectively than what OP thought of doing. But notice that it still relies on decorate-sort-undecorate for keyed sorting, and not only that but the undecoration has to be deferred until after `uniq` has made use of it, in a way that magically collapses the first decoration into something that can be used for a second sort, while adding a second decoration (the count). And then it still needs postprocessing because you can't express control over the structure of the decoration (there isn't really any, it's just string concatenation, but I mean you don't even control the order in which the pieces are concatenated).

fwlryesterday at 2:47 PM

The examples in the essay are perhaps not specific enough - they do gesture in the direction of the author’s point, but they also admit other valid interpretations like your own. I think the Rich Hickey talk “Simple Made Easy”, which this post is based on, makes the point more clearly and precisely.

(For what it’s worth, the point of both this essay and the aforementioned talk is that programs do not have to get complex, even when they get large, even when it gets hard because there are no more easy / close-at-hand / familiar helpers in the language to tackle the domain specifics. In support of this point I will note that Rich Hickey is the creator of Clojure, a language in which “building domain-specific helpers yourself” is very nearly idiomatic.)