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.<p>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.<p>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.<p>EDIT: would anyone be interested in a blog post "Rapid Prototyping in Haskell"?
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.<p>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.
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.<p>Here's the video I got the Dr Dewar quote from: <a href="https://www.youtube.com/watch?v=0yXwnk8Cr0c" rel="nofollow">https://www.youtube.com/watch?v=0yXwnk8Cr0c</a>
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.<p>There are some gems in the results section though:<p>> 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.
What this tells me most of all, is that humans will only acknowledge the legitimacy of studies that support their predetermined opinions.<p>The arguments for and against a type system like Haskell's have been going on seemingly forever, and the commonly parroted line from <i>e.g.</i>, 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!"<p>My observation is supported by section 7, "Lessons Learned".<p>> …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.…<p>> …In conducting the independent design review at Intermetrics, there was a significance sense of disbelief.<p>> …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”<p>> 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.<p>They're right. These barriers haven't disappeared overnight. They haven't even disappeared after a quarter of a century. People <i>still</i> come up with stupid reasons why they don't like Haskell.
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.