undefined | Better HN

0 pointscscheid12y ago0 comments

There is actually an interesting technical reason for having short names in generic Haskell functions. Because of parametricity, the behavior of the function doesn't depend on what the values actually are. The shortness of the names really is meant to convey "don't think about what this is doing, because it's not important for this function". In the traditional example for map,

  map f [] = []
  map f (x:xs) = f x : map f xs

You're supposed to infer from the short function names that f and x could be anything. The only important bit is that you can apply one argument to f (so, for example, f could take two parameters, and then map is just doing a single partial application). In that context, x and xs is actually a better convention than "first" and "rest", because they indicate the adherence to the type system. The naming here is saying that x is of the type of elements of xs, and that this is the only important information for map. This seriously helps in more complicated functions like zip, etc.

0 comments

dchichkov12y ago

I'm not so sure that briefness and adherence to that convention improves readability. Of course f, x, xs is much much better than 'first' and 'rest', or 'a', 'b', 'c', but something like 'func' and 'iterable' gives more context. And frees one's attention to more important things, than looking up and down the code.

Compare:

    map f [] = []
    map f (x:xs) = f x : map f xs

With:

    map f xs = [f x | x <- xs]

Or even better, in Python:

    map = lambda func, iterable: [func(x) for x in iterable]

Which one is more readable?

First one requires looking up and down in order to understand what is going on. Second one is better, context is limited to one line. And the last one doesn't require you to remember context at all.

qu4z-212y ago

I find

  map f xs = [f x | x <- xs]

the most readable, but given that list comprehension is basically a map and a filter joined together, that definition is kind of cheating.

I find the python version hardest to read (even though it's also "cheating"), which is largely because both the identifiers and the control constructs are alphabetic.

  [func(x) for x in iterable]

I have to read the words to figure out that for/in are the keywords and x/iterable are identifiers. func(x) is at least pretty obviously a function application. I'm glad it's not

  [call func x for x in iterable]

If you compare this to

  [f x | x <- iterable]

The parentheses-less function application might take some getting used to, but then it's pretty easy in my opinion. The | nicely divides it into two parts. A function application on the left, and a "take each element x out of iterable" on the right.

The only other thing is that because "iterable" is such a long word I expect it to be an identifier imported from a library or somewhere else in the program, and certainly not earlier in the line.

In summary, I think a lot of what we find "readable" depends on what we are used to.

dchichkov12y ago

>> In summary, I think a lot of what we find "readable" depends on what we are used to.

I think a general rule is that source code readability is inverse to the amount of context information that one needs to remember in order to interpret and understand the code.

If you can look at the code at any place (and at any scale, ranging from a single line to the whole call graph), and without any context understand what is happening at this particular place - code is readable. And on the opposite, if you need to know a lot about the context of each particular line of code - code is unreadable.

j / k navigate · click thread line to collapse

0 pointscscheid12y ago0 comments

  map f [] = []
  map f (x:xs) = f x : map f xs

0 comments

dchichkov12y ago

Compare:

    map f [] = []
    map f (x:xs) = f x : map f xs

With:

    map f xs = [f x | x <- xs]

Or even better, in Python:

    map = lambda func, iterable: [func(x) for x in iterable]

Which one is more readable?

First one requires looking up and down in order to understand what is going on. Second one is better, context is limited to one line. And the last one doesn't require you to remember context at all.

qu4z-212y ago

I find

  map f xs = [f x | x <- xs]

the most readable, but given that list comprehension is basically a map and a filter joined together, that definition is kind of cheating.

I find the python version hardest to read (even though it's also "cheating"), which is largely because both the identifiers and the control constructs are alphabetic.

  [func(x) for x in iterable]

I have to read the words to figure out that for/in are the keywords and x/iterable are identifiers. func(x) is at least pretty obviously a function application. I'm glad it's not

  [call func x for x in iterable]

If you compare this to

  [f x | x <- iterable]

The only other thing is that because "iterable" is such a long word I expect it to be an identifier imported from a library or somewhere else in the program, and certainly not earlier in the line.

In summary, I think a lot of what we find "readable" depends on what we are used to.

dchichkov12y ago

>> In summary, I think a lot of what we find "readable" depends on what we are used to.

I think a general rule is that source code readability is inverse to the amount of context information that one needs to remember in order to interpret and understand the code.

j / k navigate · click thread line to collapse