Haskell's code is not far away from APL. Lots of Haskell code uses single letters instead of descriptive names. This makes it a lot harder to read and forces lengthy documentation:

reverse (PS x s l) = unsafeCreate l $ \p -> withForeignPtr x $ \f -> c_reverse p (f `plusPtr` s) (fromIntegral l)

form http://www.haskell.org/ghc/docs/latest/html/libraries/bytest...

People who write code like this should be banned. Code should be written in a way to be easily read by people, not a compiler. This is not a coincidence that there are 500 lines of documentation. This is how typical Haskell code looks like.

Bytestring is a widely used library with very special performance requirements, and not a typical example of good Haskell code.

I found it here: http://www.haskell.org/haskellwiki/Example_code

Description is rather clear: "To get a feel for what real world Haskell looks like..."

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.

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.

As I said, it does not need to, because it is written in a self-descriptive.

Writing documentation for Haskell programs seems to be needed - especially short Haskell programs written by experts tends to be cryptic.

There was a second Haskell program. 8 hours to write, still far from 3 hours for Lisp.

There is no 85 line program that needs 465 lines of documentation. The developer was clearly over-zealous. The second Haskell developer was a college student who learned Haskell a week earlier; so obviously they are going to take longer.