4 ms·

As always, parametric polymorphism necessitates one-letter names, as variables can really stand for anything at all. The compiler guarantees you can't know much

by dons 14y ago

As always, parametric polymorphism necessitates one-letter names, as variables can really stand for anything at all. The compiler guarantees you can't know much (or anything) about some polymorphic variables. Other idioms come from math, e.g. 'x' for an unknown value, and then we get 'xs' for a list of unknown values. map :: (a -> b) -> [a] -> [b] map f (x:xs) = f x : map f xs Is much clearer than the Zed Shaw version: map theFunction (firstElement:otherElements) = theFunction firstElement : map theFunction otherElements

EwanToo 14y ago
In the end it's a matter of taste, I find the second version much clearer
- simias 14y ago
  I think they are both caricatural. I don't write haskell but if I did I think I'd go with: map func (first:rest) = func first : map func rest Maybe using car and cdr for first and rest because of my lisp background. That being said, for such a simple function using f, x and xs is probably fine (the way using int i; in C is fine).
  - nandemo 14y ago
    The first version is pretty standard Haskell. Certainly not caricatural. For generic code, writing first:rest is not bad but it does look a bit superfluous, somewhat like writing quotient = numerator / denominator instead of simply x = y / z. It doesn't really give you any extra information, and for me it sort of suggests that the programmer needs to remind themselves of what the operators : and / mean. Of course, if the code is not generic and the variables do have concrete meanings you should name them appropriately, e.g. roi = return / investment. But when we write x:xs it's typically polymorphic (or otherwise generic) code.
  - deleted 14y ago
    [deleted]
archivator 14y ago
I'm aware of polymorphism and the list convention and I'm not going to argue against them. However, the example code uses `c' for connection and `q' for query. Surely, knowing what those are from the variable name would be a good thing? It's not that I want to impose Obj-C's verbosity but the other extreme (1-letter names) is just as bad.
- pohl 14y ago
  It's not often discussed in polite company, but Haskell programmers are actually not Homo sapiens sapiens. They're a whole other sentient species walking invisibly among us. Their Achilles heel is the keystroke: each one like smoking a cigarette is to us (in terms of damage, not addiction). So while you and I have the luxury of calling something "connection", a Haskell programmer considers that 9 steps closer to fingertip cancer.
- nandemo 14y ago
  > However, the example code uses `c' for connection and `q' for query. Surely, knowing what those are from the variable name would be a good thing? In this case, the example is short enough that there's no chance of confusion (for the intended audience): clearly c is a connection and q is a request. They're only used in those few lines. However, I wouldn't say 1-letter names are the norm in typical Haskell code (outside type variables).

by dons 14y ago

EwanToo 14y ago

In the end it's a matter of taste, I find the second version much clearer

simias 14y ago
I think they are both caricatural. I don't write haskell but if I did I think I'd go with: map func (first:rest) = func first : map func rest Maybe using car and cdr for first and rest because of my lisp background. That being said, for such a simple function using f, x and xs is probably fine (the way using int i; in C is fine).
- nandemo 14y ago
  The first version is pretty standard Haskell. Certainly not caricatural. For generic code, writing first:rest is not bad but it does look a bit superfluous, somewhat like writing quotient = numerator / denominator instead of simply x = y / z. It doesn't really give you any extra information, and for me it sort of suggests that the programmer needs to remind themselves of what the operators : and / mean. Of course, if the code is not generic and the variables do have concrete meanings you should name them appropriately, e.g. roi = return / investment. But when we write x:xs it's typically polymorphic (or otherwise generic) code.
- deleted 14y ago
  [deleted]

archivator 14y ago

I'm aware of polymorphism and the list convention and I'm not going to argue against them. However, the example code uses `c' for connection and `q' for query. Surely, knowing what those are from the variable name would be a good thing? It's not that I want to impose Obj-C's verbosity but the other extreme (1-letter names) is just as bad.

pohl 14y ago
It's not often discussed in polite company, but Haskell programmers are actually not Homo sapiens sapiens. They're a whole other sentient species walking invisibly among us. Their Achilles heel is the keystroke: each one like smoking a cigarette is to us (in terms of damage, not addiction). So while you and I have the luxury of calling something "connection", a Haskell programmer considers that 9 steps closer to fingertip cancer.
nandemo 14y ago
> However, the example code uses `c' for connection and `q' for query. Surely, knowing what those are from the variable name would be a good thing? In this case, the example is short enough that there's no chance of confusion (for the intended audience): clearly c is a connection and q is a request. They're only used in those few lines. However, I wouldn't say 1-letter names are the norm in typical Haskell code (outside type variables).