
Haskell v Ada v C++ v Awk... An Experiment in Software Prototyping Productivity - tikhonj
http://www.haskell.org/papers/NSWC/jfp.ps
======
tikhonj
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.

------
dserban
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++.

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

------
dserban
This URL works for me:

[http://haskell.cs.yale.edu/wp-
content/uploads/2011/03/Haskel...](http://haskell.cs.yale.edu/wp-
content/uploads/2011/03/HaskellVsAda-NSWC.pdf)

~~~
agumonkey
another source, just in case
[http://webmail.cs.yale.edu/publications/techreports/tr1049.p...](http://webmail.cs.yale.edu/publications/techreports/tr1049.pdf)

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

This hard fact says more than thousand committee reviews.

~~~
TheCoelacanth
> 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.

~~~
lispm
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.

~~~
TheCoelacanth
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.

~~~
ardz
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...](http://www.haskell.org/ghc/docs/latest/html/libraries/bytestring/src/Data-
ByteString.html)

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.

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

~~~
ardz
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 for what real world Haskell looks
like..."

~~~
FreeFull
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
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.

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

------
tempodox
That link is dead.

~~~
agumonkey
These one are still alive
[https://news.ycombinator.com/item?id=7029857](https://news.ycombinator.com/item?id=7029857)

