4 ms·

I found it here: http://www.haskell.org/haskellwiki/Example_code http://www.haskell.org/haskellwiki/Example_code Description is rather clear: "To get a feel f

• FreeFull 13y ago
  I have thought about it, and my reply didn't really address what you have said. Single-letter names obviously don't improve the code's performance. The reason they tend to be used is that the values associated with each binding tend to be very generic. If you have code like id :: a -> a id x = x you can't really say anything more about what x is, since it could be anything. There are also patterns, such as xs is a list of x, and n is a number. When it's something a lot more specific, names that describe the variable's purpose should and are used. Typically, both the name of the argument and the type signature are looked at to quickly gain knowledge of what the function is probably doing. The lengthy documentation tends to be more descriptive of what the code's purpose is rather than explaining what the arguments to it are. I do acknowledge that Haskell code isn't usually too pretty to look at. I tend to find it rather readable myself, although that varies from library to library, and application to application. Applications tend to be a bit more readable than libraries, since the library implementation sometimes deals with concepts that are not exposed to the library's user.
  • ardz 13y ago
    First rule of maintanence: readable code. I should be able to read code after short introduction. I remember it took me 1h (after Sussman lecture video) to read Lisp. It is several weeks now since I'm reading Haskell tutorials and docs and still have problems to understand code advertised as "what real world Haskell looks like". It is the only language I know of which makes trivial problems hard and hard problems impossible. Because of its syntax you have to write 10x as much documentation, as experiment shows and I can confirm this from my own experience. Haskell is full of BS.