29 ms·

So if I’m parsing the results correctly they only have a single data point per language? Seems like they are testing individual programmers styles/speed just as

by atty 4y ago

So if I’m parsing the results correctly they only have a single data point per language? Seems like they are testing individual programmers styles/speed just as much as they are testing the languages.

AnimalMuppet 4y ago
And individual familiarity with their language. But if you think you can get better data, we'd all love to see it...
- kqr 4y ago
  I haven't reviewed the methodology of this first hit in detail, but here's perhaps some: https://www.researchgate.net/profile/Charles-Knutson/publication/4261726_Do_Programming_Languages_Affect_Productivity_A_Case_Study_Using_Data_from_Open_Source_Projects/links/546223460cf2c0c6aec1a663/Do-Programming-Languages-Affect-Productivity-A-Case-Study-Using-Data-from-Open-Source-Projects.pdf https://www.researchgate.net/profile/Charles-Knutson/publica... I don't think it's this one but I do remember reading a very high quality study arriving at the same result as well.
charcircuit 4y ago
They have 2 data points for Haskell since the one of the authors wrote a Haskell one which happened to have the fewest lines and highest documentation to code ratio.
- tmtvl 4y ago
  They do mention that the one you're mentioning was developed in literate programming style, where the program is a LaTeX document. I wonder what kind of an impact literate programming has on maintenance. Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable.
  - ParetoOptimal 4y ago
    > Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable. I have the expectation of a "simple" 2 lime change that took 24 hours to resolve not require more than 4 lines of commentary. However I fully admit it's not rational and try to work to change it. It helps me to remember the end goal isn't just fixing the problem, but also preserving the biggest gotchas, limitations, and most important lessons learned.
    - eschneider 4y ago
      This. I've absolutely left 20 line comments on 2 line code changes when the reason for the change is non-obvious, subtle and fairly important. I look at it as a favor for future me.
  - thesz 4y ago
    The need to document your changes would help with copy-paste, in my opinion. You would be forced to extensively document why do you repeat these 70 lines here in your code instead of using the same 70 lines elsewhere.
  - a2800276 4y ago
    > I wonder what kind of an impact literate programming has on maintenance. Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable. Reflecting on and expressing the motivation of a task and providing the rational of how you accomplished it, the alternatives you considered, etc. will obviously bring a higher cognitive load along with it than just "winging it". My guess is that for non trivial systems the benefits generally outweigh the costs. In most environments you're likely to work in, the extra "upfront" effort is unlikely to get recognized, not by one's bosses, often not even by oneself. I put upfront in quotes because I believe you don't just profit in the long term, explicitly thinking about the task and discussing / documenting the thought process generally leads to considering the problem more closely. Having a well designed and documented system probably will also cut down on those "2 line bodge fixed" that are to cumbersome to document in the long run. That said, it obviously depends on context, trivial code, throwaway code, boilerplate code exists...

by atty 4y ago

AnimalMuppet 4y ago

And individual familiarity with their language. But if you think you can get better data, we'd all love to see it...

kqr 4y ago
I haven't reviewed the methodology of this first hit in detail, but here's perhaps some: https://www.researchgate.net/profile/Charles-Knutson/publication/4261726_Do_Programming_Languages_Affect_Productivity_A_Case_Study_Using_Data_from_Open_Source_Projects/links/546223460cf2c0c6aec1a663/Do-Programming-Languages-Affect-Productivity-A-Case-Study-Using-Data-from-Open-Source-Projects.pdf https://www.researchgate.net/profile/Charles-Knutson/publica... I don't think it's this one but I do remember reading a very high quality study arriving at the same result as well.

charcircuit 4y ago

They have 2 data points for Haskell since the one of the authors wrote a Haskell one which happened to have the fewest lines and highest documentation to code ratio.

tmtvl 4y ago
They do mention that the one you're mentioning was developed in literate programming style, where the program is a LaTeX document. I wonder what kind of an impact literate programming has on maintenance. Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable.
- ParetoOptimal 4y ago
  > Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable. I have the expectation of a "simple" 2 lime change that took 24 hours to resolve not require more than 4 lines of commentary. However I fully admit it's not rational and try to work to change it. It helps me to remember the end goal isn't just fixing the problem, but also preserving the biggest gotchas, limitations, and most important lessons learned.
  - eschneider 4y ago
    This. I've absolutely left 20 line comments on 2 line code changes when the reason for the change is non-obvious, subtle and fairly important. I look at it as a favor for future me.
- thesz 4y ago
  The need to document your changes would help with copy-paste, in my opinion. You would be forced to extensively document why do you repeat these 70 lines here in your code instead of using the same 70 lines elsewhere.
- a2800276 4y ago
  > I wonder what kind of an impact literate programming has on maintenance. Can't imagine rewriting 40 lines of commentary to suit a 2 line code change to be particularly enjoyable. Reflecting on and expressing the motivation of a task and providing the rational of how you accomplished it, the alternatives you considered, etc. will obviously bring a higher cognitive load along with it than just "winging it". My guess is that for non trivial systems the benefits generally outweigh the costs. In most environments you're likely to work in, the extra "upfront" effort is unlikely to get recognized, not by one's bosses, often not even by oneself. I put upfront in quotes because I believe you don't just profit in the long term, explicitly thinking about the task and discussing / documenting the thought process generally leads to considering the problem more closely. Having a well designed and documented system probably will also cut down on those "2 line bodge fixed" that are to cumbersome to document in the long run. That said, it obviously depends on context, trivial code, throwaway code, boilerplate code exists...