This is of course a reference to a paper by Felinne Hermans et al. The thing is while the authors make a fair comparison between both activities, to me it barely touches the surface.
I’ve been calling myself a software writer from longer than I’ve been living in Norway. I don’t remember when I made the connection, but the more code I wrote in different paradigms the more clear it was that the mental work performed while typing a blog post and a program are quite similar.
In The programmer’s brain Hermans quotes research whose results suggest that natural language processing and programming activate the same regions of the brain, which is why I dare to write the following.
In Spanish the rule is to use em dashes to mark out dialogues. In English most authors use quotes. Then there’s Sally Rooney, who uses no sign, just the flow of her text. I love it. And then there’s Mariana Enríquez who in the same novel uses both, em dashes, as well as no sign at all.
I personally prefer tabs over spaces because I can configure their width according to my mood without changing the code, which is a technical argument; but it also forces me to break lines often to avoid alignment issues, which is a stylistic one. Yet most people use spaces, getting rid of the flexibility provided by tabs, favouring what leads to a purely aesthetic question: 2 or 4 spaces?
When you write a text, whether fiction or not, you have an innumerable amount of ways to say exactly the same thing. A writer my chose the clearest, less ambiguous one, or the most bold, the most brutal, or (why not?) the most confusing.
While programming you have a smaller set of options to pick from—after all programming languages are formal ones—yet the set is still big enough that you can question if a certain way is the more “readable”.
I’m a fan of higher order functions for iterating over collections regardless of the language, but especially in object oriented ones, where the benefit of composition also gives you the benefit of readability: each operation is a function call, clearly labeled, no comments needed, where to modify things becomes obvious at a glance. Except that if someone doesn’t have experience working with higher order functions, a loop isn’t only more readable, but probably looks prettier.
Which reminds me of reading. I started as a reader of pop-science magazines. I could read them for hours, no distraction. But literature was very hard. Getting in the flow of reading different genres requires to be exposed to every single one for enough time. Reading exponents of stream of consciousness in school was boring and confusing, reading them now is easy, just because I got prepared by reading enough slipstream.
So “readable” depends on what the audience is familiar with, and sometimes what’s familiar is the wrong choice.
Consider the time a colleague wrote some computation on PyTorch and compiled it to CoreML, just because Python is what he knew—there was no ML here. Its performance varied a lot depending on the device, being terrible slow on older ones. At some point it was obvious the Python implementation had to go, and we spent several weeks porting it to SIMD operations. The speed gain justified not only the effort, but also going from “here you have a nice representation of matrices, with types” to “now everything is an array full of floats”. There’s room for boldness, brutality, and confusion in programming too.
When we say that instead of modifying state, programs should be written as the composition of mathematical functions, we are talking philosophy.
I posit that “prefer composition over inheritance” summarises why prototype-based object orientation is better than class-based, even when the latter won. And that we can see how programming isn’t immune to the forces of marketing.
Where and when and how we catch errors is irrelevant once the program is running, as long as we catch them. I believe the right place is compile time. Some people believe it’s during testing, after all you need tests anyways. Others just let it crash.
When we argue about these things we really argue about how we believe things ought to be, and we theorise in the ways we want to shape the discipline. None is ultimately right nor wrong, all of them have their time and place.
The zeitgeist is that code doesn’t matter. On one hand “code is a liability”, and on the other “we won’t need to read it anymore”. Both make my blood boil because what Jane Jacobs said about writing surely applies to programming. We may have an architecture scheme, we gather requirements. We believe that once everything is correctly designed the code will flow line by line. A machine will produce it. It is like constructing buildings, and formal methods will fix it.
Yet the truth is that when we are writing code, things happen in our brains. We realise we chose the wrong abstraction. We notice things may be too slow. In horror we discover that we don’t understand the domain as much as we thought because suddenly modelling it is hard. We jump back to look at what we wrote before. We edit and edit ad nauseam. We ask for feedback. We have references of what we would like to achieve. We may have a working prototype and not be satisfied by it even when it does what it’s supposed to do.
Jacobs quote reads: “I often try writing at an early stage because writing is, for me, a rigorous form of thinking. When you put things down on those blank sheets of paper you find the holes in what you suppose. I do a lot of drafts, and a lot of discarding”. I refuse the believe I’m the only programmer out there that can relate.
Code matters, of course it does. As long as we have computers around and as long as we want to execute it. But more importantly, code matters because writing it makes us think.