
Haskell, Ada, C++: An Experiment in Prototyping Productivity (1994) [pdf] - jxub
http://haskell.cs.yale.edu/wp-content/uploads/2011/03/HaskellVsAda-NSWC.pdf
======
ff_
This is an interesting paper, and I'd like a replication today, 25y after: I
believe Haskell has matured a lot in all of this time.

As an experiment, some months ago we prototyped a new service in Haskell at
work. We timeboxed a week for it (two people, proficient in Haskell), and the
result is that (1) the Product Owners were really pleased with it, and (2)
even if it was really bad Haskell code, we _still_ managed to encode business
logic in the types so that it would always hold some important invariants. As
a result we had to fix a surprisingly small amount of things before putting it
in production.

The best thing is that as it happens we couldn't properly rewrite the
prototype, so today's service is still the same codebase, BUT it's not a
Python blob and it was such a breeze to refactor.

EDIT: would anyone be interested in a blog post "Rapid Prototyping in
Haskell"?

~~~
smu
Yes, I would be very interested!

~~~
WMCRUN
Same

------
pishpash
Trying to find the most productive language for all tasks seems like a
quixotic quest. Each language encodes a set of expressions that are succinct
to communicate, at the expense of some others. There are some basic
information theoretical and computational complexity reasons for this.

There will always be different languages that are best suited to certain
tasks, and the goal should be to make it easy (tools, systems) to work with
many languages equally well, or to allow switching anywhere like with human
languages.

------
ajxs
I believe it was Dr Robert Dewar of AdaCore fame who I first heard remark that
( paraphrased ) every time a bug gets missed at a stage of development (
compile-time to alpha, to beta, to production, etc ) the cost of it's
resolution increases by an order of magnitude. I'm certainly by no means
dismissing the value of concise languages for expressing ideas fluently, but
brevity and expressiveness are only two factors influencing the value of a
programming language in a specific domain. It's definitely an interesting
paper, every time I see it I can't help but think that it's a little
disingenuous to conduct an apples to oranges comparison of languages on these
particular merits. It's much more difficult to weigh up the relative
investment of time necessary to write code that is equally robust,
maintainable and fit for purpose.

Here's the video I got the Dr Dewar quote from:
[https://www.youtube.com/watch?v=0yXwnk8Cr0c](https://www.youtube.com/watch?v=0yXwnk8Cr0c)

~~~
fulafel
This sounds like the oft parroted but rarely fully sourced quote that turns
out to be from some 60s IBM journal, with questionable applicability to the
modern age.

see eg
[https://news.ycombinator.com/item?id=15216407](https://news.ycombinator.com/item?id=15216407)

~~~
nickpsecurity
Most evidence I've seen supports it. This is especially true when people start
integrating stuff with or building on top of a deliverable. Even more if that
stuff was designed with the deliverables good and bad behavior in mind. It
becomes a legacy system that sticks around. Knocking out its problems ahead of
time can have considerable savings. Plus, a benefit not often mentioned is
that knocking problems out at design time is easier since everything is fresh
in developers' minds. They just wrote it.

Now, it might not apply in an environment where everything is designed to be
pluggable and easy to change without breaks. Maybe folks should run some new
studies on such projects to see if there's any major benefits for up-front
investments in quality. Enough to pay off that up-front investment like in the
other projects.

------
gpapilion
This is a paper from 1994. C++ seems very different to me now vs the early
90s.

~~~
mhd
Every language in that list is vastly different from its 90s version.

~~~
sacado2
C++ changed a lot more than Ada, though. Ada was well-designed from start.

~~~
mhd
If I remember correctly, in 1994 the STL and its associated patterns were in
its utmost infancy, so compared to the old "Modern C++" or today's
lambda/task/auto C++, any language will be strong & stable.

Still, there have been _some_ changes since Ada83...

------
flukus
I love awk within certain domains, but the the overlap between where awk is
suitable and something big and complex enough to serve as a good example of
programmer productivity is essentially nil.

There are some gems in the results section though:

> It is interesting to note that the developer originally reported only 101
> lines of code, but fully admitted attempting to pack as many statements into
> each 80-column row as possible! The line count of 250 is based on looking at
> the actual code in [LBK+94] and estimating a line count based on a more
> “reasonable” notion of program formatting.

------
NikkiA
Interesting that the lisp prototype took the least amount of time to develop,
yet was considered less understable code than the haskell prototype(s).

~~~
tmm84
If it used macros I bet that had some effect on the ranking. Macros and CLOS
are two things that really take some time to sink in and understand for
programmers that don't use lisp much.

~~~
sshine
I bet it did.

In the extreme case, using macros makes every program a slightly different
DSL.

~~~
lispm
I don't think they wrote any macros.

The language they used is Common Lisp with a special library for programming
with relations on top. So they used a DSL library for relational programming.
Something like a Lisp with a kind of in-core database with a rich language for
it.

That kind of programming is extremely rare.

------
yakshaving_jgt
What this tells me most of all, is that humans will only acknowledge the
legitimacy of studies that support their predetermined opinions.

The arguments for and against a type system like Haskell's have been going on
seemingly forever, and the commonly parroted line from _e.g._ , Clojure or
JavaScript enthusiasts (like the curly-haired San Francisco guy) is that there
has never been a single study to support the idea that a type system like
Haskell's is generally a cheaper way to write reasonably robust software.
Point them to a study like this, and you're met with "Nuh-uh! Not valid!
Nope!"

My observation is supported by section 7, "Lessons Learned".

> …The reaction from the other participants, however, in particular those not
> familiar with the advantages of functional programming, was somewhat
> surprising, and is worth some discussion.…

> …In conducting the independent design review at Intermetrics, there was a
> significance sense of disbelief.

> …some observers have simply discounted the results because in their minds
> the use of higher-order functions to capture regions was just a trick that
> would probably not be useful in other contexts. One observer described the
> solution as “cute but not extensible”

> We mention these responses because they must be anticipated in the future.
> If functional languages are to become more widely used, various sociological
> and psychological barriers must be overcome. As a community we should be
> aware of these barriers and realize that they will not disappear overnight.

They're right. These barriers haven't disappeared overnight. They haven't even
disappeared after a quarter of a century. People _still_ come up with stupid
reasons why they don't like Haskell.

~~~
fnord123
>They're right. These barriers haven't disappeared overnight. They haven't
even disappeared after a quarter of a century.

The barriers disappeared since functional concepts were absorbed into other
languages. Almost all languages have higher order functions. Many languages
have a preference for immutable data. Recursion was rightly not adopted as
iterators are a better solution - keep the map/filter/fold, leave the TCO.

>People still come up with stupid reasons why they don't like Haskell

One expects that if Haskell was superior, then it would be impossible for
successful Haskell projects to materialize as they've done with Python, Go,
Rust, Java, C++. And yet, successful Haskell projects are rare. There must be
a because there is a hidden variable that this study in 1994 didn't capture.

There's certainly not a cabal of project managers forcing C++ down peoples'
throats. So instead of calling the reasons stupid, why not try to find out
what this hidden variable is?

~~~
yakshaving_jgt
> And yet, successful Haskell projects are rare. There must be a because there
> is a hidden variable that this study in 1994 didn't capture.

I'd argue that Haskell projects are just rare generally, at least partly for
the reasons described in the study. It's not debatable that so much of a
technology's adoption comes primarily down to network effects, and not a
technology's technical merit alone.

~~~
otabdeveloper1
They're rare because attempts to actually use Haskell in the field result in
disaster. When you're hiring random programmers off the street to code your
shitty business logic in Haskell, the result is a horrible mess of 'Unsafes,
exploding memory leaks and random crashes. It's a train wreck.

~~~
Jtsummers
That's why you don't hire random programmers. You hire good ones, or you
develop a training program and ensure they're good before you give them the
responsibility for making or breaking your business.

Why would anyone trust "random programmers" to some of their most critical
business efforts?

~~~
AnimalMuppet
Because random businesses don't know how to hire good programmers. (In fact,
even good businesses struggle with it.)

~~~
yakshaving_jgt
While that may be true to some extent, it doesn't further the discussion
because it makes the point moot.

For the purposes of discussing the technical merits between different
technology alternatives, we must assume some baseline competency of
programmers. Otherwise the point becomes "technology doesn't matter because
programmers are all stupid", which is not a constructive discussion.

~~~
AnimalMuppet
otabdeveloper1 said (four parents to this post) that there aren't many
successful Haskell projects because businesses can't (or at least don't) hire
good programmers. Jtsummers said to hire good ones, or train them to be good.

So in context, you could read my post as saying that run-of-the-mill companies
don't know how to hire good _Haskell_ programmers.

> For the purposes of discussing the technical merits between different
> technology alternatives, we must assume some baseline competency of
> programmers.

No. If it's harder to find good Haskell programmers than it is to find good
Python programmers, that absolutely has to be figured in. It's not a
_technical_ merit of Python or a _technical_ flaw of Haskell, but it certainly
has to be factored into the decision of which to use.

Perhaps the summary would be "Technical merit doesn't matter if all the good
programmers for that language are unavailable."

Then there's the problem that, even though we have a good track record of
hiring good C++, Java, and Objective C programmers, I am not sure that we
would be competent at selecting good Haskell programmers, even if they were
available.

So if I'm the CTO of RandomCo, I probably don't use Haskell for that new
project, no matter how technically good the language is, because I can't
identify, locate, and hire good people for the team. And bad people for the
team can turn Haskell into... something less.

~~~
yakshaving_jgt
Ok, I understand the concern, but I don’t think it reflects the market, at
least at the scale I operate in.

It’s the same as when DHH was asked about hiring Ruby developers a little over
ten years ago. The question was “why would I use Ruby when there are far fewer
developers that know it? Why not just use PHP since there are thousands of PHP
developers available?”

The answer being “how many developers do you need? Thousands? Probably not.
You probably need two or three.”

I did a hiring round for Haskellers recently for my startup, and we were
spoiled for choice. There are so many brilliant people available, and we can’t
hire them all.

------
platz
As a Haskeller, I am extremely wary of seeing this study linked to over and
over again.

------
axilmar
I do not see anything in the problem description or in the analysis of the
Haskell advantages that couldn't be handled by c++ or coded in c++ in a fairly
similar manner to Haskell so as that to have similar advantages.

~~~
vnorilo
C++ in 1994 was quite a different animal.

------
egberts
Julia is also getting there the fastest, IMHO.

------
otabdeveloper1
> Haskell and C++ from 1994

What is this, the Guild of Legacy Crap Archeology?

