Comment by crimsonalucard | Hacker News Reader

Comment by crimsonalucard | Hacker News Reader

Parent Full thread

That was just an example (I should have picked a better one). Usually, the definition won't be shorter than the name. Either way it takes a second longer to decipher the lisp then it does to read english. When composing many functions of similar complexity, it helps that the reader does not need to examine the definition of every single one. In this case, your given example would be significantly harder to understand.. See below (in haskell):

      subdivideListIntoPairsAndReturnListOfPairs .
      reverseListAndAddOneToEachElement .
      cloneListAndAppendToItself .
      multiplyAllElementsByThree $ 
      inputList

As other commenters have mentioned yes, the functions within the composition can be compositions themselves of more general functions, but my reasoning still stands. If you wrote the composition above in lisp primitives, it would be more complex and harder to decipher. Again, even with greater complexity, due to clear (but ugly) naming, the composition above does not require you to read any definitions to know exactly what it does. Your ability to comprehend what I'm doing rises because the above is written in a language most programmers understand better than any other language: English.

Also usually the "why" is longer than the "name" so if it really needs a "why", what I tend to do is write a paragraph as a block comment. Much easier to understand a paragraph, then decipher a name. However, this isn't always the case and sometimes a "why" actually delivers more clarity than the technical name. It all depends on a subjective view of what is clear.

   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)).

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