Particularly worth noting is how well a novice Haskeller performed. In particular, the novice's program took the second-least amount of time and was the second shortest. Here's a description:

> The Haskell Report was given to a newly hired college graduate, who was then given 8 days to learn Haskell. This new hire received no formal training, but was allowed to ask an experienced Haskell programmer questions as issues came up during the self study. After this training period, the new hire was handed the geo-server specification and asked to write a prototype in Haskell.

A college student who had just started learning Haskell eight days ago managed to put out a very credible prototype! Clearly, Haskell is by no means impossible to learn.

Abstract (cut-and-pasted from the paper):

We describe the results of an experiment in which several conventional programming languages, together with the functional language Haskell, were used to prototype a Naval Surface Warfare Center (NSWC) requirement for a Geometric Region Server. The resulting programs and development metrics were reviewed by a committee chosen by the Navy. The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++.

... but the Navy went with C++ for the actual system, I'll wager.

This URL works for me:

http://haskell.cs.yale.edu/wp-content/uploads/2011/03/Haskel...

another source, just in case http://webmail.cs.yale.edu/publications/techreports/tr1049.p...

Haskell vs Lisp, development time (h): 10 vs 3

This hard fact says more than thousand committee reviews.

> development times usually included documentation time

Most likely, the Haskell development time includes the time to write 465 lines of documentation, while the Lisp development time includes the time to write 12 lines of documentation. That makes it pretty obvious where the discrepancy in time comes from.

I would guess that the Lisp version was more descriptive (it had more program lines) and needed thus much less documentation than the Haskell version.

I highly doubt that an 85 line Haskell program with 465 lines of documentation had the same amount of time spent on documentation as a 274 line Lisp program with 12 lines of documentation. The Haskell developer clearly put a lot more effort into documentation.

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.

Since the Lisp developers were using 'Relational Lisp', I would guess that there were quite capable. Relational Lisp is another step up from a typical Lisp.

Only once you've measured how buggy the software is, and how much maintenance costs over the full lifecycle.

I have no such problems. Think/hack/try first, code later - this is my advice to you.

Pen and paper are my debugging tools, not a type system.

I can do that, and I've used languages and hardware where it was the only option. But I'm much faster and more effective with a type system.

Both Haskell and C++ have come a long way since 1994.

That link is dead.

These one are still alive https://news.ycombinator.com/item?id=7029857