
Haskell vs. Ada vs. C++ an Experiment in Software Prototyping Productivity (1994) [pdf] - aaronchall
http://www.cs.yale.edu/publications/techreports/tr1049.pdf
======
kazinator
Here is how I would run this experiment.

For each language, I would have two experts in that language. Call them P and
D: programmer and documenter.

They would not be permitted to communicate.

P would be required to write strictly code, without a single comment or a
shred of documentation.

D would not be permitted to view the problem description: only the input data
(along with documentation describing what the data means) and the code written
by P.

D would have to determine what the code is doing and specify the problem being
solved, relying on his or her expertise in the implementation language to
unravel how the code is treating the input data, and hence what is its
meaning.

Then evaluate the time spent by P, the time spent by D, the size the code, and
the degree to which the code actually solves the problem and the degree to
which D's documentation actually reverse-engineers the specification not
revealed to D.

Then we could say meaningful things: like a given solution is very small and
was developed quickly, but it took great effort to unravel what it's doing.
That's not bad: there are situations when that is acceptable, namely the
development of one-off solutions that will never need to be understood or
maintained, and which are needed ASAP. Situations would also reveal themselves
when the program takes long, and isn't particularly short, but is a breeze for
D to understand. Usually we would prefer that situation in permanent
production code.

The all round winner would be: small code written by P in a short amount of
time, quickly reverse-engineered by D to recover the spec. (With bonus points
for time performance, small memory use, etc).

There is also a degree of realism in this setup. How often are we called upon
to understand some code which is utterly undocumented? That's when we feel the
differences in languages, programming approaches and styles.

~~~
aninhumer
Tradeoffs in speed vs maintainability could be the intentional result of
choices made by P though. What instructions would they be given regarding how
to handle those tradeoffs?

~~~
kazinator
> _What instructions would they be given regarding how to handle those
> tradeoffs?_

"Try to win this contest to make your language look good."

P can gamble with their task at the risk of blowing up D's time.

------
platz
please stop linking this paper. it is too old, endlessly debated, and does a
disservice to any precieved motive of promoting or demoting any of the
mentioned languages.

previous discussion:

[https://news.ycombinator.com/item?id=13275288](https://news.ycombinator.com/item?id=13275288)

[https://news.ycombinator.com/item?id=7050892](https://news.ycombinator.com/item?id=7050892)

[https://news.ycombinator.com/item?id=7029783](https://news.ycombinator.com/item?id=7029783)

[https://www.reddit.com/r/programming/comments/1v0z02/haskell...](https://www.reddit.com/r/programming/comments/1v0z02/haskell_vs_ada_vs_c_vs_awk_vs_an_experiment_in/)

~~~
partycoder
And C++ has come a long way since then. A long long way. It feels almost like
a completely different language now.

~~~
atemerev
It would have been, unless the existence of the endless baggage of old C++
code to support and maintain...

~~~
partycoder
clang-tidy can be useful to modernize code.

[http://clang.llvm.org/extra/clang-
tidy/index.html](http://clang.llvm.org/extra/clang-tidy/index.html)

------
ysleepy
Hm, this paper is pretty obviously promoting Haskell. The main authors wrote
the haskell variant, did not even execute the other prototypes and make
conclusions without any sort of comparison except LOC.

I like haskell, but this paper is doing a poor job of representing scientific
honesty.

~~~
jejones3141
The people conducting the test also, without the authors' knowledge, got a
grad student, gave him eight days to learn Haskell (with no formal training,
but the option to ask a more experienced Haskell programmer questions), and
then handed him the problem spec and told him to implement it in Haskell. He
did it in eight hours with a bit under twice as many LOC as the paper's
authors' version. The paper's authors also point out issues with the study,
and describe it as showing the possible worth of functional languages, not
Haskell specifically.

------
vilhelm_s
Someone (I think John C. Peterson) mentioned this paper at the Paul Hudak
memorial symposium last year. His comment was the that the comparison was
unfair, because the Haskell program was written by Mark P. Jones, who was a
good enough programmer to outshine his competitors no matter what language. :)

~~~
di4na
[https://news.ycombinator.com/item?id=14269305](https://news.ycombinator.com/item?id=14269305)

See this for a pretty powerful rebuttal.

The second Haskell program in this paper, that also out compete everyone, was
built in a week by a grad student that did not knew Haskell before hand
without talking to the first implementer.

------
acadien
Are any of those languages even remotely similar after 25 years? For example,
C++11 is practically a different language from C++<98.

~~~
marcosdumay
Haskell changed way more than C++. I don't think Ada changed a lot.

Still, they are so different from each other that I don't think all that
change makes much of a difference.

~~~
jlarocco
Ada has had 3 major revisions since 1994. It's changed at least as much as
C++.

~~~
nom
I don't think you can compare the changes between Ada 83/95/2005/2012 to what
has happened to C++. The Ada language seems much more stable and backwards
compatible to me, and given it's nature, it makes sense to avoid introducing
major changes. However, I'm not an Ada expert so correct me if I'm wrong.

~~~
nickpsecurity
Oh, I bet you can given it's been done in detail more than once. Here's a
recent one:

[http://www.electronicdesign.com/embedded/c11-and-
ada-2012-re...](http://www.electronicdesign.com/embedded/c11-and-
ada-2012-renaissance-native-languages)

------
solomatov
There might be many biases in this research. If one is able to write code in
Haskell it tells a lot about them, and he might be a better programmer than
one who writes in Ada or C++.

To make this research unbiased we need to do the following:

* Take people who are profecient in Ada, Haskell and Ada

* Randomly assign them to different teams

* Compare their results

~~~
jlarocco
> If one is able to write code in Haskell it tells a lot about them, and he
> might be a better programmer than one who writes in Ada or C++.

And here's the arrogant, self-important attitude that turned me off of
Haskell.

When I was using it, I didn't see any evidence that Haskell users are any
better or worse than programmers in any other language.

If it were true, why aren't Haskell developers taking over the world with
their superior software?

In reality, any new, interesting language is going to attract better than
average developers at first, because those developers are always learning new
stuff and trying different things.

~~~
Peaker
> And here's the arrogant, self-important attitude that turned me off of
> Haskell.

Haskellers are usually out to convince that Haskell is for most programmers,
and that "need PhD to use it" is a myth.

It is people frustrated by the (difficult) learning curve of Haskell that say
such things.

~~~
jlarocco
> It is people frustrated by the (difficult) learning curve of Haskell that
> say such things.

And there it is again. I haven't drank the Haskell kool-aid, so I must not be
smart enough to use it properly.

~~~
codygman
> If one is able to write code in Haskell it tells a lot about them, and he
> might be a better programmer than one who writes in Ada or C++. - solomatov

> And here's the arrogant, self-important attitude that turned me off of
> Haskell. - jlarocco

> It is people frustrated by the (difficult) learning curve of Haskell that
> say such things. - peaker

> And there it is again. I haven't drank the Haskell kool-aid, so I must not
> be smart enough to use it properly.

Firstly, reading "people frustrated by the difficult learning curve of haskell
say such things" as "I haven't drank the Haskell kool-aid, so I must not be
smart enough to use it properly." is a __very __uncharitable interpretation.

Secondly, I believe solomatov and Peaker's comments could be written more
unambiguously as follows (though I thought they were precise enough):

solamatov commment rewrite: Someone who can write Haskell might be a better
programmer than programmers who use other languages because Haskell is
difficult to learn.

peaker comment rewrite: People frustrated by the difficulty of the Haskell
learning curve say things such as "Someone who managed to learn Haskell to the
point they can write code in it have proven their worth more than those who
use easier to learn languages"

So jlarocco, could you still call classify these comments and the thought
processes behind them arrogant and self important? Is there anything that
would turn you off of them?

------
bwackwat
I enjoyed the paper, thanks. I am now inspired to rewrite some C++ in Haskell.

Anyone have a modern example of this type of research? Opinions are welcome!

------
lispm
Basically 'Relational Lisp' won. Just three hours development time.

~~~
marcosdumay
And a write-only prototype.

I'm sure it could become more readable with some more time invested.

~~~
kazinator
Can you let others know where you were able to download this?

~~~
marcosdumay
What it says about the Lisp implementation:

> The documentation size is also quite low, which may partially account for
> this [low implementation time].

It then got a B in understandability, what is the lowest grade on that
dimension.

~~~
lispm
> The documentation size is also quite low

You can guess that it is very declarative code, given that they used a Lisp
with high-level facilities on top.

~~~
marcosdumay
I'm not going back into the article, but there's a "code reads like
documentation" dimension on the evaluation. I don't remember it getting a top
score there.

~~~
lispm
But got an A in the table for "Executable Specification", that's what
'declarative programming' actually means. One specifies/declares WHAT to do
and the system figures out HOW to do it. Relational Lisp supports this on a
'logical'/'relational' level.

------
jejones3141
BTW... in the diagram showing the regions of interest for a given set of craft
and their positions, some of them are referred to as "doctrines". Anyone know
what "doctrine" means in this context?

------
arnon
I'd like to see a more recent evaluation of this.

