Hacker News Reader

Comment by pherq | Hacker News Reader

   pairwise .
   reverse . map (+1) .
   flatten . replicate 2 .
   map (*3) $
   input

With all the functions being pretty standard (pairwise is my own name for subdivideListEtc, but it seems like a terse name that still explains what the operation is). Every fragment in this composition is smaller than the names you supplied, and all but one of them are standard Prelude functions that should be considered basic knowledge in Haskell. In addition, since the standard functions have parameters passed as values (rather than being part of the name like multiplyAllElementsByThree), this approach is easier to tinker with if one value was wrong (1 change, rather than 3 (name of function at definition, at use, and value in function definition)).

View on HN

More elegant, more concise but less understandable. This is subjective but I would argue it's harder to get a higher level understanding of what your code is doing versus what mine is. Also, honestly, nobody will know what "pairwise" is without looking at the definition; I mean the name is appropriate and elegant, but that doesn't mean it's clear.

Here's another perspective: My code, despite having several complicated procedures, had naming that was so utterly clear you were able to implement the entire thing based off of the naming alone. I didn't have to explain anything to you, I didn't have to write any comments, yet you understood it within a second after reading it. Could one say the same about your code?

Assuming basic knowledge of Haskell, there's not much between them (one function definition that takes all of two lines).

Both of them clearly show what the function is doing in an operational sense, but neither give any high-level indication of what the whole thing is for. They don't say whether this is part of the computation of a hash function, or a format conversion, or what have you -- that takes documentation and proper naming. These just tell you a way of turning one random list into another.

I think both versions of the code need to be wrapped with an appropriate name. That name is necessarily more functional, as too much is happening to describe technically. After being named, that name would be sufficient for most readers. For those for whom it isn't sufficient, who are interested in the implementation, it can go two ways: either they like that your version explains the algorithm in words, or they dislike it for introducing an extra layer of indirection around 'trivial' function calls, while they are interested in the actual implementation.

I think your expanded example may be a bit of a special case, because it is at the level where for anything 'larger', technical names would be unwieldy or imprecise, while for anything smaller, abstraction would basically be aliasing. I think most commenters, or I at least, were erring towards the interpreting the original example as one of the first category. The large example shows how it could be appropriate.

I disagree on the understandable part.

But another point is that it is much easier to have a typo that compiles in code than in variable names.

Reply on news.ycombinator.com