10 ms·

Haskell vs. Ada vs. C++ vs. an Experiment in Prototyping Productivity (1994) [pdf]

73 points by mkristiansen 2y ago

mkristiansen 2y ago
My favorite part of this is the fact that the Haskell solution is considered "too clever".
- qayxc 2y ago
  I think the reaction by many people would still be same 30 years later today. Tooling and standardization sure helped with C++, but the authors pointed out the psychological and sociological barriers involved. While some of these barriers have eroded in the past decades (evolving imperative languages incorporated more and more functional aspects over time), but pure functional languages are still perceived as "too clever" by many. I also wonder how the literate programming approach taken with the Haskell solution compares to the "test harness" used by the C++ implementation in terms of documentation. It has been shown that people read code differently from prose and tests suites are somewhat comparable to the "executable specification" that literate programming provides, with the former aligning more closely with reading the implementation. It'd be interesting to conduct a similar study today with more contemporary contestants like Haskell, C++20, Rust, Python (it's about prototyping after all), Java, C#/F#, and Julia. It'd also be intriguing to learn whether the perception of the functional solutions changed over time.
- crote 2y ago
  "Clever" code is an anti-feature. Writing code is already hard enough as-is due to the complexity imposed by business requirements. On top of that, reading and debugging code is significantly harder than writing it. It is extremely easy to end up with an incredibly clever codebase, which in practice is just a completely unmaintainable mountain of technical debt. Take for example something like the Fast Inverse Square Root algorithm [0]. It is incredibly clever, but if you randomly come across it most developers won't be able to easily understand how it works. The well-known variant uses undefined behavior, gives a suboptimal result, and doesn't have any meaningful comments. In other words: it cannot be maintained. Having one or two of those in places where they are absolutely necessary isn't a too bad, but imagine having to deal with bugs in a codebase where you come across stuff like this every single day. Writing clever code is easy. It is far harder and way more important part to write simple code. [0]: https://en.wikipedia.org/wiki/Fast_inverse_square_root https://en.wikipedia.org/wiki/Fast_inverse_square_root
  - kccqzy 2y ago
    That's not an anti-feature because of cleverness. It's a failure of engineering. Just like everything else, clever code needs to be encapsulated behind a good interface, be well documented, be well tested. > if you randomly come across it most developers won't be able to easily understand how it works So document it. > uses undefined behavior So fix the undefined behavior. Use memcpy or bit_cast. > gives a suboptimal result That's probably intentionally sacrificing accuracy for speed. Document it. > doesn't have any meaningful comments Then add it. Clever algorithms is never the problem by itself. It's undocumented unencapsulated clever algorithms with unknown bugs.
    - dwattttt 2y ago
      Maybe the best example of this would be memcpy. It's extremely clear what it does, but the implementations would surely be "clever" code. And yet you don't need to know anything about SSE to use it.
denismenace 2y ago
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.
- kubb 2y ago
  But they hired someone capable of learning. 99% of developers will not learn a language that doesn’t look familiar to them on principle. They don’t like it and it’s the end of discussion.
  - bluGill 2y ago
    There are a lot of developers that won't even learn new things about their current language. I'm still fighting to get some people to adopt C++11 which is 13 years old now.
    - rramadass 2y ago
      I used to think this sort of "unreasonable" mindset was a characteristic of "old fogies" and "bright young'uns" always knew better. But ever since i moved from the latter to the former group years ago i began to understand this mindset. It is basically a fear of losing the expertise one has acquired over a long career through a language which has become almost second nature. Also with time and experience you become very cautious about trying out new things in production code because you still don't understand the ramifications fully. For all its complexity, pre C++11 was far simpler to understand and write code in. We knew the minefields and what to avoid and how to model effectively. So most of us are not a fan of new additions to the language every 3 years just because the committee members are trying to ape other languages. Speaking for myself, i only wanted a concurrency library and some compile-time programming constructs as new additions to the language, everything else was strictly not necessary. Looked at from the above viewpoint, you should be able to appreciate us "old fogies" mindset and why we refuse to eagerly jump on the C++11 (and later) bandwagon just because it exists. We need a justification for every new thing we are forced to re-learn and use. So my suggestion is to take one new feature at a time, discuss and convince the folks of its utility, maybe make the changes in one single module and demonstrate it. The argument of "its new and shiny" will never fly with us.
jasode 2y ago
Previous discussion that includes even more backlinks to additional earlier discussions: https://news.ycombinator.com/item?id=14267882 https://news.ycombinator.com/item?id=14267882
- dang 2y ago
  Thanks! Macroexpanded: Haskell, Ada, C++, Awk: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=33936366 https://news.ycombinator.com/item?id=33936366 - Dec 2022 (49 comments) Haskell, Ada, C++: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=19570776 https://news.ycombinator.com/item?id=19570776 - April 2019 (55 comments) Haskell vs. Ada vs. C++ an Experiment in Software Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=14267882 https://news.ycombinator.com/item?id=14267882 - May 2017 (59 comments) Haskell vs. Ada vs. C++ vs. Awk vs (1994) [pdf] - https://news.ycombinator.com/item?id=13275288 https://news.ycombinator.com/item?id=13275288 - Dec 2016 (68 comments) Haskell, Ada, C++, Awk: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=7050892 https://news.ycombinator.com/item?id=7050892 - Jan 2014 (24 comments) Haskell v Ada v C++ v Awk... An Experiment in Software Prototyping Productivity - https://news.ycombinator.com/item?id=7029783 https://news.ycombinator.com/item?id=7029783 - Jan 2014 (23 comments)
krona 2y ago
(1994)
- dang 2y ago
  Added above. Thanks!
medo-bear 2y ago
TLDR: "Haskell vs Ada vs C++" but a lisp wins in development hours by huge margin I wonder if this is the 'relational lisp' in question https://www.ap5.com/ap5-man.html https://www.ap5.com/ap5-man.html or https://ieeexplore.ieee.org/document/13081 https://ieeexplore.ieee.org/document/13081
- lispm 2y ago
  From what I understand, there was a successor to AP5 called Relational Lisp (-> rellisp). I don't think I've seen the source for that. AP5 is available and there have been updates to the implementation since many years.
jlouis 2y ago
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...
- ilrwbwrkhv 2y ago
  Its especially sad to see many YC companies falling for writing JavaScript.
  - epolanski 2y ago
    No it's not why would it? Monocole-wielding elitist opinions like these scream to me very low productivity environments that would spend weeks on reinventing the wheel rather than getting to market fast. I love and practice Haskell, but anybody thinking that technologies like these are fit for fast moving startups are absolutely delusional. You can easily setup a monorepo and release quickly mobile/native/web/apis and whatever with excellent editor and ecosystem support in TypeScript, good luck achieving that on alternative languages. Last but not least, 99% of people like you criticizing JavaScript have never seen what kind of great goodies there are in the ecosystem, even for writing pure functional programming that scales, e.g. with Effect-ts[1] [1] https://effect.website/ https://effect.website/
    - atq2119 2y ago
      Paul Graham is a major Lisp advocate, attributing a non-trivial part of his own early success to it. So there are all those good reasons for it, but it's still a little weird.
      - epolanski 2y ago
        No, PG advocating for Lisp because he has had a good experience with it 30 years ago is not a "good reason". Build a tech team around lisp in your startup then task somebody with scraping a website or handling session tokens refreshing and see the results. At some point people should ask themselves why there's so little killer software written in Lisps or pure functional languages (besides extremely rare exceptions like Emacs or Datomic) when modest and much hated languages like PHP have plenty.
xvilka 2y ago
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.
- bluGill 2y ago
  Also be interesting (but impossible) do this with more complex problems. I work on more than 10 million lines of C++ (large, but there are many larger C++ codebases out there), with much of the code going back 15 years (comparatively young), with several hundred developers . Even if Haskell could do this in 1 million lines of code (seems unlikely, but who knows), that is still a lot of code. Does it have the abstraction needed to handle this, or does something fail and haskell becomes unmaintainable for some reason? Which is to say this is interesting, but it is a microbenchmark and so of questionable relevance to the real world.
  - iand675 2y ago
    I work on one of the largest Haskell codebases in the world that I know of (https://mercury.com/ https://mercury.com/). We're in the ballpark of 1.5 million lines of proprietary code built and deployed as effectively a single executable, and of course if you included open source libraries and stuff that we have built or depend on, it would be larger. I can't really speak to your problem domain, but I feel like we do a lot with what we have. Most of our pain comes from compile times / linking taking longer than we'd prefer, but we invest a lot of energy and money improving that in a way that benefits the whole Haskell ecosystem. Not sure what abstractions you are wondering about, though.
    - bluGill 2y ago
      What I'm wondering about is how maintainable programs of that size are over time. That you get get over a million lines says it is possible. However difficult is it though? Abstractions are just code for whatever it is needed to break your problems up between everyone without conflicts. How easy/hard is this? For example, I like python for small programs, but I found around 10-50k LOC python no longer is workable as you will make a change not realizing that function is used elsewhere and because that code path isn't covered in tests you didn't know about the breakage until you ship.
wslh 2y ago
(1994)
black_13 2y ago
[dead]
AnimalMuppet 2y ago
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.) 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, and then maintain it for a decade or three. (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.) 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 how fast it was developed affect that? 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...)
- marcosdumay 2y ago
  Yes, Haskell isn't anything near good enough on this test.
- pragma_x 2y ago
  There is also the very real-world consideration of: How do I hire people to maintain this beast? Sometimes, you have to bow to industry trends. Otherwise, you're one or two resignations away from being dead in the water. A Haskell solution might be svelte and easy to reason about, for a Haskell programmer. But you have to also be prepared to train new hires on all that, and you may not have that lead time.
emmelaich 2y ago
(1994)
- dang 2y ago
  Added above. Thanks!
deknos 2y ago
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.
nycombinatorm 2y ago
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.
keyserj 2y ago
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"). Some thoughts on the experiment: - 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. - 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? - 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".
- marcosdumay 2y ago
  > to me, these reactions would reduce the success for the understandability (and learnability?) criterion You say that of the submission that was sent back to the authors to complete the actual code instead of just sending pseudocode...
  - keyserj 2y ago
    Does it say that the submission was sent back? For the "suspicious" people, this seems to imply the code was final: > It is significant that [people] were all surprised and suspicious when we told them that Haskell prototype P1 (see appendix B) is a complete tested executable program. For the people critiquing "cleverness", that seems completely valid whether or not it's actual code or pseudocode.
    - marcosdumay 2y ago
      You can complain about at most 1 of "it's hard to read" and "it's too simple, it doesn't look like you wrote the entire code".
James_K 2y ago
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.
dleslie 2y ago
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. It describes Relational Lisp as being Lisp enhanced with a database-like language for logic programming. I suspect this may be it: https://oceanpark.com/ap5.html https://oceanpark.com/ap5.html https://www.ap5.com/ https://www.ap5.com/ There's a C2 entry for it, of course: https://wiki.c2.com/?RelationalLispWeenie https://wiki.c2.com/?RelationalLispWeenie
davidavidavid 2y ago
coment
rramadass 2y ago
Under "Lessons Learned" section; 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: 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." 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). 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.

73 points by mkristiansen 2y ago

mkristiansen 2y ago

My favorite part of this is the fact that the Haskell solution is considered "too clever".

qayxc 2y ago
I think the reaction by many people would still be same 30 years later today. Tooling and standardization sure helped with C++, but the authors pointed out the psychological and sociological barriers involved. While some of these barriers have eroded in the past decades (evolving imperative languages incorporated more and more functional aspects over time), but pure functional languages are still perceived as "too clever" by many. I also wonder how the literate programming approach taken with the Haskell solution compares to the "test harness" used by the C++ implementation in terms of documentation. It has been shown that people read code differently from prose and tests suites are somewhat comparable to the "executable specification" that literate programming provides, with the former aligning more closely with reading the implementation. It'd be interesting to conduct a similar study today with more contemporary contestants like Haskell, C++20, Rust, Python (it's about prototyping after all), Java, C#/F#, and Julia. It'd also be intriguing to learn whether the perception of the functional solutions changed over time.
crote 2y ago
"Clever" code is an anti-feature. Writing code is already hard enough as-is due to the complexity imposed by business requirements. On top of that, reading and debugging code is significantly harder than writing it. It is extremely easy to end up with an incredibly clever codebase, which in practice is just a completely unmaintainable mountain of technical debt. Take for example something like the Fast Inverse Square Root algorithm [0]. It is incredibly clever, but if you randomly come across it most developers won't be able to easily understand how it works. The well-known variant uses undefined behavior, gives a suboptimal result, and doesn't have any meaningful comments. In other words: it cannot be maintained. Having one or two of those in places where they are absolutely necessary isn't a too bad, but imagine having to deal with bugs in a codebase where you come across stuff like this every single day. Writing clever code is easy. It is far harder and way more important part to write simple code. [0]: https://en.wikipedia.org/wiki/Fast_inverse_square_root https://en.wikipedia.org/wiki/Fast_inverse_square_root
- kccqzy 2y ago
  That's not an anti-feature because of cleverness. It's a failure of engineering. Just like everything else, clever code needs to be encapsulated behind a good interface, be well documented, be well tested. > if you randomly come across it most developers won't be able to easily understand how it works So document it. > uses undefined behavior So fix the undefined behavior. Use memcpy or bit_cast. > gives a suboptimal result That's probably intentionally sacrificing accuracy for speed. Document it. > doesn't have any meaningful comments Then add it. Clever algorithms is never the problem by itself. It's undocumented unencapsulated clever algorithms with unknown bugs.
  - dwattttt 2y ago
    Maybe the best example of this would be memcpy. It's extremely clear what it does, but the implementations would surely be "clever" code. And yet you don't need to know anything about SSE to use it.

denismenace 2y ago

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.

kubb 2y ago
But they hired someone capable of learning. 99% of developers will not learn a language that doesn’t look familiar to them on principle. They don’t like it and it’s the end of discussion.
- bluGill 2y ago
  There are a lot of developers that won't even learn new things about their current language. I'm still fighting to get some people to adopt C++11 which is 13 years old now.
  - rramadass 2y ago
    I used to think this sort of "unreasonable" mindset was a characteristic of "old fogies" and "bright young'uns" always knew better. But ever since i moved from the latter to the former group years ago i began to understand this mindset. It is basically a fear of losing the expertise one has acquired over a long career through a language which has become almost second nature. Also with time and experience you become very cautious about trying out new things in production code because you still don't understand the ramifications fully. For all its complexity, pre C++11 was far simpler to understand and write code in. We knew the minefields and what to avoid and how to model effectively. So most of us are not a fan of new additions to the language every 3 years just because the committee members are trying to ape other languages. Speaking for myself, i only wanted a concurrency library and some compile-time programming constructs as new additions to the language, everything else was strictly not necessary. Looked at from the above viewpoint, you should be able to appreciate us "old fogies" mindset and why we refuse to eagerly jump on the C++11 (and later) bandwagon just because it exists. We need a justification for every new thing we are forced to re-learn and use. So my suggestion is to take one new feature at a time, discuss and convince the folks of its utility, maybe make the changes in one single module and demonstrate it. The argument of "its new and shiny" will never fly with us.

jasode 2y ago

Previous discussion that includes even more backlinks to additional earlier discussions: https://news.ycombinator.com/item?id=14267882 https://news.ycombinator.com/item?id=14267882

dang 2y ago
Thanks! Macroexpanded: Haskell, Ada, C++, Awk: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=33936366 https://news.ycombinator.com/item?id=33936366 - Dec 2022 (49 comments) Haskell, Ada, C++: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=19570776 https://news.ycombinator.com/item?id=19570776 - April 2019 (55 comments) Haskell vs. Ada vs. C++ an Experiment in Software Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=14267882 https://news.ycombinator.com/item?id=14267882 - May 2017 (59 comments) Haskell vs. Ada vs. C++ vs. Awk vs (1994) [pdf] - https://news.ycombinator.com/item?id=13275288 https://news.ycombinator.com/item?id=13275288 - Dec 2016 (68 comments) Haskell, Ada, C++, Awk: An Experiment in Prototyping Productivity (1994) [pdf] - https://news.ycombinator.com/item?id=7050892 https://news.ycombinator.com/item?id=7050892 - Jan 2014 (24 comments) Haskell v Ada v C++ v Awk... An Experiment in Software Prototyping Productivity - https://news.ycombinator.com/item?id=7029783 https://news.ycombinator.com/item?id=7029783 - Jan 2014 (23 comments)

krona 2y ago

(1994)

dang 2y ago
Added above. Thanks!

medo-bear 2y ago

TLDR: "Haskell vs Ada vs C++" but a lisp wins in development hours by huge margin I wonder if this is the 'relational lisp' in question https://www.ap5.com/ap5-man.html https://www.ap5.com/ap5-man.html or https://ieeexplore.ieee.org/document/13081 https://ieeexplore.ieee.org/document/13081

lispm 2y ago
From what I understand, there was a successor to AP5 called Relational Lisp (-> rellisp). I don't think I've seen the source for that. AP5 is available and there have been updates to the implementation since many years.

jlouis 2y ago

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...

ilrwbwrkhv 2y ago
Its especially sad to see many YC companies falling for writing JavaScript.
- epolanski 2y ago
  No it's not why would it? Monocole-wielding elitist opinions like these scream to me very low productivity environments that would spend weeks on reinventing the wheel rather than getting to market fast. I love and practice Haskell, but anybody thinking that technologies like these are fit for fast moving startups are absolutely delusional. You can easily setup a monorepo and release quickly mobile/native/web/apis and whatever with excellent editor and ecosystem support in TypeScript, good luck achieving that on alternative languages. Last but not least, 99% of people like you criticizing JavaScript have never seen what kind of great goodies there are in the ecosystem, even for writing pure functional programming that scales, e.g. with Effect-ts[1] [1] https://effect.website/ https://effect.website/
  - atq2119 2y ago
    Paul Graham is a major Lisp advocate, attributing a non-trivial part of his own early success to it. So there are all those good reasons for it, but it's still a little weird.
    - epolanski 2y ago
      No, PG advocating for Lisp because he has had a good experience with it 30 years ago is not a "good reason". Build a tech team around lisp in your startup then task somebody with scraping a website or handling session tokens refreshing and see the results. At some point people should ask themselves why there's so little killer software written in Lisps or pure functional languages (besides extremely rare exceptions like Emacs or Datomic) when modest and much hated languages like PHP have plenty.

xvilka 2y ago

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.

bluGill 2y ago
Also be interesting (but impossible) do this with more complex problems. I work on more than 10 million lines of C++ (large, but there are many larger C++ codebases out there), with much of the code going back 15 years (comparatively young), with several hundred developers . Even if Haskell could do this in 1 million lines of code (seems unlikely, but who knows), that is still a lot of code. Does it have the abstraction needed to handle this, or does something fail and haskell becomes unmaintainable for some reason? Which is to say this is interesting, but it is a microbenchmark and so of questionable relevance to the real world.
- iand675 2y ago
  I work on one of the largest Haskell codebases in the world that I know of (https://mercury.com/ https://mercury.com/). We're in the ballpark of 1.5 million lines of proprietary code built and deployed as effectively a single executable, and of course if you included open source libraries and stuff that we have built or depend on, it would be larger. I can't really speak to your problem domain, but I feel like we do a lot with what we have. Most of our pain comes from compile times / linking taking longer than we'd prefer, but we invest a lot of energy and money improving that in a way that benefits the whole Haskell ecosystem. Not sure what abstractions you are wondering about, though.
  - bluGill 2y ago
    What I'm wondering about is how maintainable programs of that size are over time. That you get get over a million lines says it is possible. However difficult is it though? Abstractions are just code for whatever it is needed to break your problems up between everyone without conflicts. How easy/hard is this? For example, I like python for small programs, but I found around 10-50k LOC python no longer is workable as you will make a change not realizing that function is used elsewhere and because that code path isn't covered in tests you didn't know about the breakage until you ship.

wslh 2y ago

(1994)

black_13 2y ago

[dead]

AnimalMuppet 2y ago

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.) 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, and then maintain it for a decade or three. (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.) 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 how fast it was developed affect that? 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...)

marcosdumay 2y ago
Yes, Haskell isn't anything near good enough on this test.
pragma_x 2y ago
There is also the very real-world consideration of: How do I hire people to maintain this beast? Sometimes, you have to bow to industry trends. Otherwise, you're one or two resignations away from being dead in the water. A Haskell solution might be svelte and easy to reason about, for a Haskell programmer. But you have to also be prepared to train new hires on all that, and you may not have that lead time.

emmelaich 2y ago

(1994)

dang 2y ago
Added above. Thanks!

deknos 2y ago

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.

nycombinatorm 2y ago

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.

keyserj 2y ago

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"). Some thoughts on the experiment: - 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. - 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? - 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".

marcosdumay 2y ago
> to me, these reactions would reduce the success for the understandability (and learnability?) criterion You say that of the submission that was sent back to the authors to complete the actual code instead of just sending pseudocode...
- keyserj 2y ago
  Does it say that the submission was sent back? For the "suspicious" people, this seems to imply the code was final: > It is significant that [people] were all surprised and suspicious when we told them that Haskell prototype P1 (see appendix B) is a complete tested executable program. For the people critiquing "cleverness", that seems completely valid whether or not it's actual code or pseudocode.
  - marcosdumay 2y ago
    You can complain about at most 1 of "it's hard to read" and "it's too simple, it doesn't look like you wrote the entire code".

James_K 2y ago

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.

dleslie 2y ago

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. It describes Relational Lisp as being Lisp enhanced with a database-like language for logic programming. I suspect this may be it: https://oceanpark.com/ap5.html https://oceanpark.com/ap5.html https://www.ap5.com/ https://www.ap5.com/ There's a C2 entry for it, of course: https://wiki.c2.com/?RelationalLispWeenie https://wiki.c2.com/?RelationalLispWeenie

davidavidavid 2y ago

coment

rramadass 2y ago

Under "Lessons Learned" section; 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: 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." 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). 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.