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.
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.
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.
I've never used literate programming in a large project, but I have used it a few times at work and my experience is mostly that you are right. In a team where you'll have accumulated knowledge among team members about a codebase you are working in regularly, the benefit to literate programming seemed to be very quickly outstripped by the maintenance burden.
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.
Really smart putting the runbook automation and the docs all in one place.
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 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...
> 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.
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.
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.
