Programming as Theory Building, Naur (1985). PDF-link
Posted by patrixxxx@reddit | programming | View on Reddit | 16 comments
Posted by patrixxxx@reddit | programming | View on Reddit | 16 comments
omgpop@reddit
IMO this is a very productive perspective, though maybe more normative than descriptive per se. Obviously there are many possible accounts of what a “theory” is, but it is usually thought of, roughly, as some kind of compact set of statements aiming to describe the stable rules governing the behaviour of a system. A good theory will enable prediction and predictable intervention on a system.
There are analogies and disanalogies to programming. The most obvious disanalogy is that there is no globally fixed target system a program (or a programmer’s mental model) should correspond to. Programs exist within systems, or function within systems, but they don’t strictly map to extant systems that might be explained. Naur might say that the program itself is not the theory, but just an artefact representing the theory - this just pushes the point back a level.
In science at least, a theory is good or bad in function of how closely it models some fixed underlying reality, and a beautiful theory can be thrown out wholesale pending the result of a single key experiment. Programmers are influenced by the constraints of the systems they build for/within, but they also influence back. The systems may bend to the program as much as the program might bend to the system. A bug can become someone’s favourite feature, and a new programming capability can create entirely new system behaviours.
What’s interesting and productive to me about the comparison is that many of the features of a good theory are also features of good software. An ideal theory is something so simple you could write it on the back of an envelope, yet with that explain a huge range. Good software abstraction is like a theory unification that lets you do more with less, (though in science it’s only good if it takes you closer to the truth).
A good theory is also something understandable to humans. A statistical model that predicts with a high degree of accuracy is scientifically worth far less than a handcrafted model with a few well understood parameters, even if the latter has a lower R^2 or whatever. Of course the analogy to AI codegen writes itself, and I half suspect that’s why this article is getting popular again. I have a few people I know I’d like to share it with.
shawncplus@reddit
This is absurd and can easily be disproven by just ramping it up. On one hand you have a magical box that answers any question you give to it with 100% accuracy but it never shows its work, on the other hand you have a pile of trash that is just... a pile of trash that you keep throwing heaps of questions written on pieces of paper; it doesn't provide any answers whatsoever but you do know what's in there and maybe even once in a blue moon the outgassing of the trash will make a noise but it certainly isn't going to be an answer to any of your questions. Which of those two has more worth scientific worth?
omgpop@reddit
I don't know if you thought this was meant to be a serious reductio, or...?
_I_AM_A_STRANGE_LOOP@reddit
I really like this comment. Re: your closing point, it made me think of how humans were adept at the process of making machines of various sorts for millenia, but we didn't have Newtonian physics until the 18th century. I see a lot of coding unfold as something like the process of making a ship or trebuchet in antiquity. The diagrams of one of those devices were/are dramatically more complex than the fundamental axioms defining Newton's physics, yet they carry MUCH less meaningful semantic content if the reader wants to go on to make novel devices which differ from the referents. I think it's very easy to conflate the complexity of something with its semantically-loaded value, and I feel this kind of thing really does rhyme a lot with codegen navel-gazing.
Arakela@reddit
The most abstract definition is this: We name a thing to map one or more descriptions of it.
That is MAD grammar that can describe structures of: syntax, possible interactions to universally define systems boundary, process interleavings for a linguistic scheduler, and much more than "Backus-Naur Form" can imagine.
screener_kev@reddit
The Naur paper might be the single most-shared CS paper I've never heard anyone fully agree with. People link it as a hammer for whatever argument they're making, half the time it's "see, you can't replace senior devs with juniors" and half the time it's "see, documentation is useless." Neither is what he actually said. The real claim is that the program is the team's theory of the problem and the source code is a partial transcript of that theory. Lose the team, lose the theory, and what's left compiles but doesn't extend cleanly. Worth re-reading every few years.
Chisignal@reddit
Even in this thread there are obvious misunderstandings of the paper, people are so eager to use it to prove their own views and take so shortcuts
patrixxxx@reddit (OP)
In "Programming as Theory Building" (1985), Peter Naur argues that programming is fundamentally a human activity of building a mental "theory"—a deep conceptual insight into how a system's parts match the real-world problem it solves. He rejects the prevailing view that programming is merely the mechanical production of source code, specifications, and documentation. Instead, Naur posits that the true product of programming is the shared mental model held in the minds of the developers who built it. A program is considered "alive" only as long as its team possesses this living theory, which guides them in making natural, cohesive modifications. When the group of programmers who understand this theory disperses or leaves the project, the program is effectively "dead." Even if the source code and thousands of pages of documentation survive completely intact, the fundamental understanding of the system's design philosophy is lost. A dead program can still be executed and even mechanically modified, but doing so is perilous. Without the original theory, new maintainers will treat the software as a black box, resulting in patchwork fixes that introduce unexpected side effects and accelerate architectural decay. Ultimately, Naur concludes that software maintenance is not a routine clerical task, but the highly creative act of continuously regenerating and extending the program's underlying theory in the minds of the developers.
SneakySnoggs@reddit
Someone could inform most of my past bosses, who instead wanted their tickets completed as quickly and with as little commotion as possible.
alchebyte@reddit
Indeed. and if you use AI generated code without understanding it, the theory never happens.
cognitive debt == technical debt, with several orders of magnitude greater pay back.
larsga@reddit
I was working at a where we collected web traffic from hundreds of websites and shuffled it around for lots of different kinds of analysis. I started building a new subsystem, which was not a trivial thing to do, given the volume of data and the near-realtime constraints.
One of the other developers was objecting, saying that he wasn't sure this would work, when the manager interrupted, saying basically that developing a new subsystem was always, basically, "testing a hypothesis".
I've thought about that a lot since, because it's really always how I work when developing something new that's substantial. I try to plan it out in advance and convince myself it's going to work. If it passes that stage I do the next trial, which may be a prototype, or it may be building the production version. At each step I'm not just building the thing, but equally much verifying that it will actually work as intended.
But it's really only after it's been in production for a couple of years that the hypothesis can be considered fully proven. At every point before that you have to be prepared to change tack or give up based on the results you get.
And failure can be "users don't understand it", "reliability isn't good enough", "the code is too difficult to work with", "the abstractions are too clumsy", or whatever.
patrixxxx@reddit (OP)
Great points.
Saint_Nitouche@reddit
WillemDaFo@reddit
I love this, nice one!
rismay@reddit
Sooo true.
roman12323@reddit
One of the most underrated papers in software engineering. Naur's argument that programming is about building understanding, not just producing code, still feels relevant today.