8 ms·
Haskell vs. Ada vs. C++ an Experiment in Software Prototyping Productivity (1994) [pdf]
- acadien 9y agoAre any of those languages even remotely similar after 25 years? For example, C++11 is practically a different language from C++<98.
- digitalzombie 9y agoOne counter argument is that you're still building on the same foundation. Likewise C++ isn't going to be as concise as Haskell ever. So the paper still hold some truth if not mostly valid.
- cies 9y agoThe conclusion mentioned some interesting truisms about prototyping, team-size-induced-complexity and "long bugs" vs "short bugs". Good stuff. If the PDF was not a collection of images of the text, i'd have copy-pasted that bit here. :)
- marcosdumay 9y agoHaskell 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 9y agoAda has had 3 major revisions since 1994. It's changed at least as much as C++.
- doublec 9y agoNot to mention the changes to the SPARK subset of Ada for doing proofs on parts of your code have improved a lot.
- nom 9y agoI 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 9y agoOh, 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-renaissance-native-languages http://www.electronicdesign.com/embedded/c11-and-ada-2012-re...
- flogic 9y agoThe paper is dated 94 which is the same year as the original implementation as the C++ STL (https://en.wikipedia.org/wiki/Standard_Template_Library#Implementations https://en.wikipedia.org/wiki/Standard_Template_Library#Impl...). So it's a fair bet they didn't have access to that. I would think the entire difficulty of the exercise would change with that.
- flukus 9y agoIf I were to jump into a random c++ project, which version would I expect to find?
- acadien 9y agoIf it was written before 1998 I expect you'd find a version of C++ that existed before 1998 :) If it was written today, I don't know that's a really good question. I think its a mistake to ignore the advances that 2011 and 2014 bring to the table though.
- oselhn 9y agoI do not think that someone wants to use C++11/14 to make app prototype. There are a lot more languages now which in my opinion are better suited to prototyping than languages mentioned in article. Most of people will use Python, JS or some other scripting language.
- deleted 9y ago[deleted]
- solomatov 9y agoThere 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 9y ago> 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 9y ago> 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 9y ago> 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 9y ago> 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?
- solomatov 9y agoThere 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
- bwackwat 9y agoI 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!
- ysleepy 9y agoHm, 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.
- emef 9y agoThey added many disclaimers saying that LOC alone is a bad metric and it's more interesting to look at characteristics of the code for anecdotes. The article is full of of advice to take the findings with a grain of salt. They don't even mention haskell in the conclusion, they just say that functional programming is well-suited to rapid prototyping.
- jejones3141 9y agoThe 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.
- lispm 9y agoBasically 'Relational Lisp' won. Just three hours development time.
- marcosdumay 9y agoAnd a write-only prototype. I'm sure it could become more readable with some more time invested.
- kazinator 9y agoCan you let others know where you were able to download this?
- marcosdumay 9y agoWhat 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.
- deleted 9y ago[deleted]
- lispm 9y ago> 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 9y agoI'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 9y ago
- vilhelm_s 9y agoSomeone (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. :)
- gertef 9y ago> Paul Hudak Ah :-) > memorial symposium Oh no :-(
- deleted 9y ago[deleted]
- di4na 9y agohttps://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.
- platz 9y agoplease 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_vs_ada_vs_c_vs_awk_vs_an_experiment_in/ https://www.reddit.com/r/programming/comments/1v0z02/haskell...
- deleted 9y ago[deleted]
- syockit 9y agoofftopic: I've never posted any links on HN before, but is there no confirmation page upon submitting that tells you the link has been submitted before?
- kornish 9y agoIf you post the same link as someone else shortly after them, you'll just get redirected the current discussion page and I believe it counts as an upvote to the article. If sufficient time has elapsed since the last posting, HN allows links to be re-posted since peoples' viewpoints may have shifted, modern events may influence discussion, etc.
- partycoder 9y agoAnd C++ has come a long way since then. A long long way. It feels almost like a completely different language now.
- _pmf_ 9y agoTemplate metaprogramming still sucks. And will keep sucking with concepts.
- 9y ago
- jejones3141 9y agoBTW... 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?
- kazinator 9y agoHere 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 9y agoTradeoffs 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 9y ago> 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.
- arnon 9y agoI'd like to see a more recent evaluation of this.