Hacker News Reader

Comment by kazagistar | Hacker News Reader

> Also, what's up with all the single-letter variable names?

Words are not useful if your variables don't really have semantically meaningful names. Also, if your code is a simple one-liner, it does not really add too much benefit to name everything, if it is obvious from the (very local) context.

For example, when I look at something like:

    ordered (x:y:xs) = x <= y && ordered (y:xs)

I could do something like:

    ordered (first:second:remainingList) = first <= second && ordered (second:remainingList)

... but if anything, that will make it harder to read.

View on HN

Then why did you call your variables x and y, and not y and x? Surprise: because there IS a semantic meaning to the order.

The haskell variable naming convention is bad. What is worse is that when someone points it out, there is ALWAYS this one or two variable example being put forward, when the problem exists in the 90% of functions that have 5 or more variables in scope.

I see a lot of haskell code that looks like FORTRAN. Haskell code is yet not written in large companies where there is a readability requirement. I just hope more programmers with a better taste for readability joins the Haskell ranks. The readability story needs to improve (and I see it improving a bit..)

>> Haskell code is yet not written in large companies where there is a readability requirement

As a counterargument: Haxl at Facebook. https://github.com/facebook/Haxl

The convention isn't terrible, it's just a convention and takes a bit to get used to. The (x:y:xs) pattern is useful for when you could at best describe x and y as thing1 and thing2 and xs as theRestOfTheThings. Since the extra letters add no real clarity it's not a bad way to keep things concise. Once you get used to the pattern it's better because if you see (x:y:xs) you know that the things themselves are less important than their order out of an array.

> Haskell code is yet not written in large companies where there is a readability requirement

Yes it is.

> What is worse is that when someone points it out, there is ALWAYS this one or two variable example being put forward, when the problem exists in the 90% of functions that have 5 or more variables in scope.

I would bet a fair amount of money that 90% of Haskell functions do not have 5 or more variables in scope.

> Haskell code is yet not written in large companies where there is a readability requirement.

Haskell code is not yet written in large amounts in large companies (or anywhere else). Haskell code is, however, written in large companies.

Also: Large companies have a readability requirement? I'm not so sure that they do, that it's enforced, or that it's effective. I;m especially not sure that it's effective to the point that an outsider can read it.

> Haskell code is not yet written in large amounts in large companies (or anywhere else).

Haskell code isn't written in large amounts anywhere? Define large amounts.

For instance the GHC codebase itself is pretty large.

In my Python code I find that readability and naming conventions are very important. Usually in my Haskell code I'm writing more abstract functions where a good specific name isn't possible or it's obvious what it's referring to because of the type signature.

It is a lot less of a problem then you make out: most of the time, the single letter naming conventions are actually very useful. Its not like all the haskellers just forgot the usefulness of names from the other languages they frequently use; it is an educated and measured choice.

That said, it certainly can be taken too far and turn into a clusterfuck.

    permutations            :: [a] -> [[a]]
    permutations xs0        =  xs0 : perms xs0 []
      where
        perms []     _  = []
        perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is)
          where interleave    xs     r = let (_,zs) = interleave' id xs r in zs
                interleave' _ []     r = (ts, r)
                interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r
                                         in  (y:us, f (t:y:us) : zs)

    addart a = array ((-1,0),(n,m+n)) $ z ++ xsi ++ b ++ art ++ x
      where z = ((-1,0), a!(0,0)) : [ ((-1,j),0) | j <- [1..n] ] ++ [ ((-1,j+n),a!(0,j)) | j <- [1..m] ]
            xsi = ((0,0), -colsum a 0) : [ ((0,j),0) | j <- [1..n] ] ++ [ ((0,j+n), -colsum a j) | j <- [1..m] ]
            b = [ ((i,0), a!(i,0)) | i <- [1..n] ]
            art = [ ((i,j), if i == j then 1 else 0) | i <- [1..n], j <- [1..n] ]
            x = [ ((i,j+n), a!(i,j)) | i <- [1..n], j <- [1..m] ]
            ((_,_),(n,m)) = bounds a

From Matrix.Simplex https://hackage.haskell.org/package/dsp-0.2.1/docs/src/Matri...

https://hackage.haskell.org/package/dsp-0.2.1/docs/src/Matri... link to the function itself

Never really seen something like this before, really hope someone will clean it up

To be fair it looks to be a relatively complex operation. Do you know how any other languages implement this?

This is not about the complexity of the code, but about variables with or without meaningful names.

I feel like xsi and art mean something domain specific that might be obvious to a domain expert.

Reply on news.ycombinator.com