I'm curious about Relational Lisp. It had the shortest development time, 3h to Haskell's 10/8; a middling/low number of lines of code, at 274; and only 12 lines of documentation.<p>It describes Relational Lisp as being Lisp enhanced with a database-like language for logic programming.<p>I suspect this may be it:<p><a href="https://oceanpark.com/ap5.html" rel="nofollow">https://oceanpark.com/ap5.html</a><p><a href="https://www.ap5.com/" rel="nofollow">https://www.ap5.com/</a><p>There's a C2 entry for it, of course:<p><a href="https://wiki.c2.com/?RelationalLispWeenie" rel="nofollow">https://wiki.c2.com/?RelationalLispWeenie</a>
They also assumed Haskell performed so well, because the author was an expert at it. So, they independently hired a college graduate with no prior knowledge of Haskell and gave him 8 days to learn it. Turns out the graduate implemented the second best solution in terms of lines of code and development time.
Would be nice to redo this experiment with modern languages like Rust, Go, as well as modern "flavors" of Haskell and C++. Maybe throw OCaml in as well.
Previous discussion that includes even more backlinks to additional earlier discussions: <a href="https://news.ycombinator.com/item?id=14267882">https://news.ycombinator.com/item?id=14267882</a>
It's interesting that we've known results such as these for 30(+) years, yet 99.999% of all software is still written in outright miserable languages such as Python or Javascript...
Interesting. I think it's the wrong test, though. (I mean, look, it's hard to get data on actual software engineering. They got actual data, and they published it. It's more than most people ever do.)<p>I think the real test would be to do the same experiment, but not with a prototype. It would be to write a finished program, <i>and then maintain it for a decade or three</i>. (But of course, nobody's ever going to run that experiment - it would be too expensive, plus the time is too long for the "publish or perish" world.)<p>The point is, more matters than just "how fast can I develop". How fast can I develop code that can be maintained for a long time by other people? How hard is it for them to maintain? How does the choice of language affect that? How does <i>how fast it was developed</i> affect that?<p>In the real world, speed of development is only one variable, and maybe not the most important one. (And, yes, I'm complaining about the data being inadequate, after noting earlier how rare it was to get data at all...)
Wow.I read the article when it first came out. Periodically, it gets re-posted.
My take on the article now is still what I thought then.
When hiring a team of SW engineers to build something, it
is critical to choose a language that a large number of
potential candidates know - "know" as in have already written
tens of thousands of line of; Concurrent Euclid might be
a great language (dating me) but the pool of engineers who
really know it is vanishing small.
What I find interesting is that the Haskell solution was the only one to use higher order functions. Assuming they also count virtual functions in languages like C++ to be higher order, I think a part of the difference here is in design attitude rather than an inherent part of the languages studied.
I really like the idea of comparing languages in a real-ish scenario of development, written by independent expert-in-language developers! As a web dev, I'm particularly interested in the idea of this for comparing the various web frameworks (including "no framework").<p>Some thoughts on the experiment:<p>- To get a better idea of the impact of the language on authors' thought processes, it'd probably have to include submissions from more authors in each language. With just one (or so) submission per language, I could see there being variation in expertise.<p>- I'm curious to see what the documentation looks like here, that there's so much written in some of the submissions, and that the paper authors value it so highly. Is it used to explain what the code does, indicating potentially too-complex code, or is it explaining whys?<p>- In the "Lessons Learned" section, it's mentioned that other reviewers were not as impressed with Haskell. I'm curious if their reactions were included in the evaluation - to me, these reactions would reduce the success for the understandability (and learnability?) criterion. The paper authors seem to have written this off as "If functional languages are to become more widely used, various sociological and psychological barriers must be overcome".
Under "Lessons Learned" section;<p><i>Haskell appeared to do quite well in the NSWC experiment; even better than we had anticipated! 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.
There were two kinds of responses:<p>In conducting the independent design review at Intermetrics, there was a significance sense of disbelief. We quote from [CHJ93]: "It is significant that Mr. Domanski, Mr. Banowetz and Dr. Brosgol were all surprised and suspicious when we told them that Haskell prototype P1 (see appendix B) is a complete tested executable program. 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 specification and top level design. They were convinced it was incomplete because it did not address issues such as data structure design and execution order."<p>The other kind of response had more to do with the "cleverness" of the solution: it is safe to say that 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" (para-phrasing); this comment slipped its way into an initial draft of the final report, which described the Haskell prototype as being "too cute for its own good" (the phrase was later removed after objection by the first author of this paper).<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.</i>
they should redo this and add rust. not because rust is the new hype, but productivity and security also depends on the ecosystem. and all have their different stances, issues and points.
TLDR: "Haskell vs Ada vs C++" but a lisp wins in development hours by huge margin<p>I wonder if this is the 'relational lisp' in question<p><a href="https://www.ap5.com/ap5-man.html" rel="nofollow">https://www.ap5.com/ap5-man.html</a><p>or<p><a href="https://ieeexplore.ieee.org/document/13081" rel="nofollow">https://ieeexplore.ieee.org/document/13081</a>