Good names can help making comments less important.
OTOH, comment can give you the best(?) of both worlds, both revealing the linear structure of the function, while still providing extra information:
oddSquareSum :: Integer oddSquareSum = sum -- add together . takeWhile (<10000) -- until a value >10K is seen . filter odd -- all the odd . map (^2) -- squares of $ [1..] -- natural numbers
-k
Hmm. My 0.03$ (to whole thread): 1. I prefer the concept of pipeline. - It gives me feeling that I'm not interested in the order of computation (map all values to square, then filter the odds) but rather with semi-parallel computation (which is really what is happening). Let syntax, being much more flexible, may give semi-imperative approach (although much more mixed). - I read that average human remembers up to 7-10 things in short term memory - why garbage it with variables? On the other hand more complex computation may require let/where and/or arrows helper functions. For example: filter (\x -> case x of Nil -> False; _ -> True) ... or filter (\x -> case x of Nil -> False _ -> True) ... is less clear then filter (not . isNil) ... where isNil Nil = True isNil _ = False 2. The comments in the above example are too verbose for my taste. It is like (in imperative program): x = x + 1; // add 1 to x Anyone having minimal knowledge about syntax will be able to deduce the comment directly from the line so why repeat it. However: c = ~c | (c && 0xFF000000); // Invert the color in ARGB Is meaningful comment. There is little information what the line does and it may happen that the operation must be done efficiently (inner loop). 3. While name should be meaningful (oddSquereSum is not - however it IMHO is permissible in let/where) if project have documentation and function is exported it should have documentation. While name is part of documentation it cannot replace it.