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.
But if you think you can get better data, we'd all love to see it...
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.
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.
There is an exception though: runbook automation. When I write scripts to automate work that comes up when I'm on call, I try to write them in a literate style when I can, and commit them to a runbooks repo. The extra documentation is a lot more beneficial because they tend to be things that people aren't looking at regularly, and someone might be looking at it because of a 3am page or some urgent outage, so having a lot of documentation up front can be a big benefit.
Yeah, when I was on call, I'd have an ipython notebook up and running with access to all the systems I need to extract data and information from for doing investigative analysis. I feel like my intelligence drops 10% when a P1 would come in. Being able to map IDs in one system to another system so you can access a specific log can reduce much of the chaos.
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.
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...