Hacker News new | past | comments | ask | show | jobs | submit login

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.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: