Another day, another post telling me to do something, or not do something, or adopt some technology, or not adopt some technology, or whatever it is that they want me to do, because it makes it easier to “reason about the code”.
It’s a scam.
More precisely, it’s a thought-terminating cliche. Ironic, as the phrase “reason about” is used as a highfalutin synonym for “think about”. The idea is that there’s nowhere to go from here. I want to do things one way, some random on medium dot com wants me to do things another way, their way makes it easier to reason about the code, therefore that’s the better approach.
It’s a scam.
Let’s start with the fact that people don’t think—sorry, reason—about things the same way. If we did, then there’d be little point to things like film review sites, code style guides, or democracy. We don’t know precisely what influences different people to think in different ways about different things, but we have some ideas. Some of the ideas just raise other questions: like if you say “it’s a cultural difference” then we have to ask “well, why is it normal for all of the people in that culture to think this way, and all of the people in this culture to think that way?”
This difference between modes of thought arises in computing. We know, for example, that you can basically use any programming language for basically any purpose, because back in the days when there were intellectual giants in computering they demonstrated that all of these languages are interchangeable. They did so before we’d designed the languages. So choice of programming language is arbitrary, unless motivated by external circumstances like which vendor your CTO plays squash with or whether you are by nature populist or contrarian.
Such differences arise elsewhere than in choice of language. Comprehension of paradigms, for example: the Smalltalk folks noticed it was easier to teach object-oriented programming to children than to professional programmers, because the professional programmers already had mental toolkits for comprehending programming that didn’t integrate with the object model. It’s easier for them to “reason about” imperative code than objects.
OK, so when someone says that something makes it easier to “reason about” the code, what they mean is that that person find it easier to think about code in the presence of this property. I mean, assuming they do, and are not disingenuously proposing a suggestion that you do something when they’ve run out of reasons you should do it but still think it’d be a good idea. But wait.
It’s a scam.
Code is a particular representation of, at best, yesterday’s understanding of the problem you’re trying to solve. “Reasoning about code” is by necessity accidental complexity: it’s reflecting on and trying to understand a historical solution of the problem as you once thought it was. That’s effort that could better be focussed on checking whether your understanding of the problem is indeed correct, or needs updating. Or on capturing a solution to an up-to-the-minute model of the problem in executable form.
This points to a need for code to be deletable way faster than it needs to be thought about.
Reasoning about code is a scam.
it depends. For me “reason about code” means for be able to formalize correctness proof (much the same way an article in math journal does not have _formal_ proof, but rather a proof a professional mathematician can formalize). I think about formal in terms of Dijkstra’s (structured programming) and Hoare’s (communicating sequential processes) formalism.
It’s a scam. Your purpose for “reasoning about” the code—to construct headproofs in the way you think maths papers work—is not necessary. A computer can do it. Look at modern maths journals and you’ll see computer-generated proofs abound.
The second reason for the scam is that a logical proof of your software is irrelevant, when your software is twenty-five lines of typescript that show an inaccurate prediction of when an Uber driver will get from where we only incorrectly believe they are to where we only incorrectly believe their destination to be. Processes in software may be logical, but they are modelling requirements from the real world that are not logical. The requirements may, in the strictest cases, be rational rather than logical, but aren’t even that.
Headproofs of internal logic are accidental complexity. The essential complexity lies in the mapping of weird real-world processes into software. Stop reasoning about your code, and start replacing it.
If you can guarantee simple properties about a module’s behavior, that makes the module’s user-facing interface simpler. Otherwise, a user of the module has to know its implementation details, so that they can anticipate how it’s going to behave. Sometimes, you can provide a proof for those properties, and that’s a very nice place to be.
It’s true that the real world is messy and uncertain, but that only increases the value of making your system’s internal interactions as simple and predictable as possible.
Pingback: Reasoning about code is a scam | ProgClub
Pingback: Structure and Interpretation of Computer Programmers » “Best practice” is less of a scam than claimed