Haskell, Ada, C++, Awk: An Experiment in Prototyping Productivity (1994) [pdf] | Hacker News Reader

Haskell, Ada, C++, Awk: An Experiment in Prototyping Productivity (1994) [pdf]

haskell.cs.yale.edu

56 pointslelf24 comments

"Them" refers to the developers using languages other than Haskell:

"We provided them with a copy of P1 without explaining that it was a program, and based on preconceptions from their past experience, they had studied P1 under the assumption that it was a mixture of requirements speciﬁcation and top level design. They were convinced it was incomplete because it did not address issues such as data structure design and execution order.”

"The other kind of response had more to do with the 'cleverness' of the solution...[one of them] described the Haskell prototype as being 'too cute for its own good'.

These both sound like they could have been written today.

Reminds me of this from the Incomplete and Mostly Wrong History of Programming Languages:

Haskell gets some resistance due to the complexity of using monads to control side effects. Wadler tries to appease critics by explaining that 'a monad is a monoid in the category of endofunctors, what's the problem?'

Admittedly, "too cute for its own good" is a pretty fair description of a lot of Haskell.

Over-engineering definitely does seem to be a problem in very-expressive programming languages. Probably has more to do with the reasons most people use Haskell rather than with Haskell itself.

There is another really nice paper from 2000 by Lutz Prechelt called ”An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl” (http://page.mi.fu-berlin.de/prechelt/Biblio/jccpprt2_advance...)

This paper compared several properties of 80 implementations of a set of requirements. It compared properties such as run time, memory consumption, source text length, time expended developing the solution, comment density, reliability and program structure.

Overall, even though there are some obvious threats to validity, I find this work quite read-worthy.

Might be a good idea to stick "1994" in the title of this post. This paper is almost 20 years and things have happened since.

It would be interesting to see how things have developed since 1994. Could you recommend more recent references on the topic?

What is the topic? If you're interested in seeing the current state of the languages involved then I think a quick online search will find you all you want.

If the topic is other experiments like this one, then I don't know. I think the idea is fundamentally flawed. There are just too many variables involved. A good litmus test is to ask yourself if you'd be able to independently reproduce the results of the experiment.

I've been recently studying comparisons of programming languages/programming semantics and I've been reading papers on the subject. While I do not have strictly relevant papers (I swear I had but I can't find them right now, sorry), if you're interested on a broader subject, this could help:

* What is the Impact of Static Type Systems on Programming Time? (http://ecs.victoria.ac.nz/foswiki/pub/Events/PLATEAU/2009Pro...)

* Heuristic Evaluation of Programming Language Features: Two Parallel Programming Case Studies (http://ecs.victoria.ac.nz/foswiki/pub/Events/PLATEAU/Program...)

* Do Programming Languages Affect Productivity? A Case Study Using Data from Open Source Projects (http://sequoia.cs.byu.edu/lab/files/pubs/Delorey2007a.pdf)

They are all (mostly) recent papers, at least post-2005. Furthermore, the Plateau international workshop might have some more material of interest: https://sites.google.com/site/workshopplateau/

ps: this Thursday/Friday in Delft (NL - Europe) there will be a conference related on the subject of programming languages, it's free and might interest someone: http://eelcovisser.org/wiki/future-of-programming

EDIT: fixed second link

You gave the same link for the first two studies you mention. Also, it's pretty easy to detect the author's heavy bias against type systems just from a quick perusal of the first page. The methodology used is extremely questionable, not to mention that he doesn't even consider languages with type inference.

Whoops! Sorry, you're correct. I apologize for the wrong link (fixed now).

And yeah, I agree that some studies are a bit biased (it's hard to find objective studies with a proper applied method). I just wanted to share some findings that might have been interesting to the reader and let him/her take home his/her own considerations on the matter. Entirely agree with you though.

Not just biased, but also quite ignorant:

>No-such-method exceptions mainly occur because of null-pointer exceptions (which occur in typed programming languages as well)

Null is a solved problem. Completely and totally solved. The fact that he didn't know this is pretty amazing.

Posted only 4 days ago: https://news.ycombinator.com/item?id=7029783

Coincidence or synchronicity? I posted a link to the very same paper one day ago without knowing about the other submission: https://news.ycombinator.com/item?id=7043915 Why does everyone remember that paper now :-)?.

I commented on this in another thread where it came up[1]. My main takeaway from this is that they had a ridiculously good lisper handy. Quite literally less than half of the time of the next fastest implementation! That is insane.

[1] https://news.ycombinator.com/item?id=7044797

I was taught programming at University with a combination of Ada and Haskell (In the first two years at least, year 3 & 4 used whatever was appropriate for the module)

It has "Haskell" in the domain name, it sounds quite biased to favor Haskellers, as well as the fact that the paper is dated.

Good thing you caught on to Yale's conspiracy to trick you into using haskell. Now avert your gaze lest you be corrupted.

We're now 20 years on, and still hardly anybody uses Haskell. This is just a guess, but maybe it's not going to catch on..

I don't think you're paying very much attention.

Outside the HN bubble, I mean.

EDIT: I stand corrected; there is a Haskell job listed at the moment: http://www.indeed.com/q-Haskell-jobs.html

Have fun in Reston, VA!

The types of coding work hired out through job boards, and the types of coding work Haskell is good for, are not intersecting sets.

Implying Haskell should only be used in the ivory tower? Just because it can be abstract doesn't mean you can't do CRUD apps with Haskell - why not?

What a language can do, and what a language is uniquely suited for, are distinct concepts. You can do CRUD apps in Haskell--but writing a CRUD app doesn't suggest Haskell, and so you won't likely hire Haskell people to write you a CRUD app.

I didn't mean to imply that Haskell's specialty lies anywhere near the ivory tower, either. It seems to me closer to a replacement for Ada in writing provable-yet-optimized software.

Tomato vs tomàto vs tomáto vs tomatö

Reply on news.ycombinator.com