4 ms·

> It's a sad state of reality, because it drives down the quality of software to the common denominator of fresh junior devs, which is not much. There's no rea

by pron 7y ago

> It's a sad state of reality, because it drives down the quality of software to the common denominator of fresh junior devs, which is not much. There's no reality here, just myth. That switching to Java would drive quality up makes at least as much sense as it driving it down. If you're referring to the particular languages, then the reality is that no big effect has been found for the choice of programming language on software quality. As lack of evidence in favor of a big effect is evidence of its lack, the most probable explanation is that no such effect exists (it's possible a small effect exists, but we don't know in which language's favor). And, indeed, while there is a theory explaining (and even predicting ahead of time) why there is no big effect to the choice of the programming language, not only is there no empirical evidence suggesting there is such an effect, there is no theory to predict it, either. That language has a big effect on quality is, at this point, no more than wishful thinking among a minority of developers who are big programming language fans. It's a bedtime story. (I am not saying that language didn't ever have a big effect or that it never will, just that both theory and observation show that there isn't one currently among "reasonable" languages in common use; also, I have used and I like both Java and Clojure) And if you're only referring to the priority of making the project more accessible, then I don't understand your comment at all. There are many, many more experienced Java developers than experienced Clojure developers, and experienced developers are at least as likely not to bother learning a new language in order to contribute to a project (although perhaps for different reasons). Picking a popular language makes the project more accessible to experienced developers. What has been shown to drive quality up or down is process. If you have a good process, then making the project more accessible can help, and if you don't then you're screwed anyway.

lvh 7y ago
If we're going to talk about empirical effects, we first need to agree on what quality means. Parts of the thread, including your comment, lead me to believe we sometimes mean an abstract, desirable but ineffable property--but then we're not speaking empirically. Do you mean "defect rate" or something else?
- pron 7y ago
  I mean any reasonable metric you pick. The studies that have tried and failed to find a big effect used defect rate as a metric, but studies are not the only way to detect big effects. Because there are strong selective pressures in industry that can detect big effects, we can say that no big effect on the bottom line has been found.
tempguy9999 7y ago
> then the reality is that no big effect has been found for the choice of programming language on software quality Substantiate that. I say it's garbage. <https://www.cse.iitk.ac.in/users/karkare/courses/2010/cs653/Papers/hudak_haskell_sw_prototype.pdf> https://www.cse.iitk.ac.in/users/karkare/courses/2010/cs653/..., and this BTW is from 1994 so this evidence has been around for ages Language LOC Documentation Lines Dev time (hours) (1)Haskell 85 465 10 (2)Ada 767 714 23 (3)Ada9X 800 200 28 (4)C++ 1105 130 – (5)Awk/Nawk 250 150 – (6)Rapide 157 0 54 (7)Griffin 251 0 34 (8)Proteus 293 79 26 (9)RelationalLisp 274 12 3 (10)Haskell 156 112 8 (Edit: all aligned with tabs but looks like they've been stripped. See paper instead) comments of note: (2) The Ada solution was written by a lead programmer at NSWC; in this sense it represents the “control” group. The developer initially reported a line count of only 249; this was the numberof lines of imperativestatements as reported by theSun Adacompiler, anddid notinclude declarations, all of which were essential for proper execution. The line count of 767 is based on the actual code in and does not include lines with only termination characters. (4) TheC++solutionwaswrittenbyanONRprogrammanagerafterhavingfirstwrittentheAwk solution described in the next paragraph. In addition to these 1105 lines of code, the developer also wrote a 595-line “test harness.” No development times were reported [Note: C++ has evolved a lot since then, but perhaps so has haskell] (10) Intermetrics, independently and without the knowledge of NSWC or Yale University, con-ductedan experimentof its own: theHaskell Report was given to anewly hiredcollege graduate, who was then given 8 days to learn Haskell. This new hire received no formal training, but was allowed to ask an experienced Haskell programmer questions as issues came up during the self study. After this training period, the new hire was handed the geo-server specification and asked to write aprototype in Haskell. Theresulting metrics shown in row 10 ofthe tableare perhaps the most stunning of the lot, suggesting the ease with which Haskell may be learned and effectively utilized. Also mentioned was "The use of higher-order functions [in haskell] is noteworthy" so language features did help. Actual evidence. > As lack of evidence in favor of a big effect is evidence of its lack yeah right. Let me rephrase that for you - Lack of knowledge by an HN poster is not evidence of lack of evidence. > What has been shown to drive quality up or down is process Evidence please? My experience is that process can be rigorous but useless crap. My old boss said "process is not sufficient to produce quality, but it is a necessary" There's plenty more in that PDF, please read it.
discreteevent 7y ago
Peter Norvig made a comment here that agrees with you about process and architecture over language (he was talking about why he started using python instead of lisp) "In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice." https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815

by pron 7y ago

lvh 7y ago

If we're going to talk about empirical effects, we first need to agree on what quality means. Parts of the thread, including your comment, lead me to believe we sometimes mean an abstract, desirable but ineffable property--but then we're not speaking empirically. Do you mean "defect rate" or something else?

pron 7y ago
I mean any reasonable metric you pick. The studies that have tried and failed to find a big effect used defect rate as a metric, but studies are not the only way to detect big effects. Because there are strong selective pressures in industry that can detect big effects, we can say that no big effect on the bottom line has been found.

tempguy9999 7y ago

> then the reality is that no big effect has been found for the choice of programming language on software quality Substantiate that. I say it's garbage. <https://www.cse.iitk.ac.in/users/karkare/courses/2010/cs653/Papers/hudak_haskell_sw_prototype.pdf> https://www.cse.iitk.ac.in/users/karkare/courses/2010/cs653/..., and this BTW is from 1994 so this evidence has been around for ages Language LOC Documentation Lines Dev time (hours) (1)Haskell 85 465 10 (2)Ada 767 714 23 (3)Ada9X 800 200 28 (4)C++ 1105 130 – (5)Awk/Nawk 250 150 – (6)Rapide 157 0 54 (7)Griffin 251 0 34 (8)Proteus 293 79 26 (9)RelationalLisp 274 12 3 (10)Haskell 156 112 8 (Edit: all aligned with tabs but looks like they've been stripped. See paper instead) comments of note: (2) The Ada solution was written by a lead programmer at NSWC; in this sense it represents the “control” group. The developer initially reported a line count of only 249; this was the numberof lines of imperativestatements as reported by theSun Adacompiler, anddid notinclude declarations, all of which were essential for proper execution. The line count of 767 is based on the actual code in and does not include lines with only termination characters. (4) TheC++solutionwaswrittenbyanONRprogrammanagerafterhavingfirstwrittentheAwk solution described in the next paragraph. In addition to these 1105 lines of code, the developer also wrote a 595-line “test harness.” No development times were reported [Note: C++ has evolved a lot since then, but perhaps so has haskell] (10) Intermetrics, independently and without the knowledge of NSWC or Yale University, con-ductedan experimentof its own: theHaskell Report was given to anewly hiredcollege graduate, who was then given 8 days to learn Haskell. This new hire received no formal training, but was allowed to ask an experienced Haskell programmer questions as issues came up during the self study. After this training period, the new hire was handed the geo-server specification and asked to write aprototype in Haskell. Theresulting metrics shown in row 10 ofthe tableare perhaps the most stunning of the lot, suggesting the ease with which Haskell may be learned and effectively utilized. Also mentioned was "The use of higher-order functions [in haskell] is noteworthy" so language features did help. Actual evidence. > As lack of evidence in favor of a big effect is evidence of its lack yeah right. Let me rephrase that for you - Lack of knowledge by an HN poster is not evidence of lack of evidence. > What has been shown to drive quality up or down is process Evidence please? My experience is that process can be rigorous but useless crap. My old boss said "process is not sufficient to produce quality, but it is a necessary" There's plenty more in that PDF, please read it.

discreteevent 7y ago

Peter Norvig made a comment here that agrees with you about process and architecture over language (he was talking about why he started using python instead of lisp) "In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice." https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815