> This might be unusual but I would prefer to read someone's mental model of how the code works than the code itself.
The hypothesis under Peter Naur's (the N on BNF) "Programming as Theory Building" paper is that transmitting (by talking) the mental model is far more important than other format of documentation to understand a system.
> I would prefer to read someone's mental model of how the code works than the code itself.
I find this is often true for me. If there's a bunch of code that I'm having a particularly hard time understanding, it's usually because I don't actually have a working mental model of what the thing is supposed to do.
Problem is, with complex systems often the way to record the mental model is something like a design document, and getting programmers (including myself) to write thoughtful natural language to accompany our code is a constant uphill battle against business pressures to ship more.
> I think this is more akin to construction workers asking for blueprints rather than cad models.
No, because those aim to express the same thing, albeit with different limitations and practical considerations. Code and math are entirely separate things.
> As someone who hasn't actively done formal math in a couple of decades the slog of relearning syntax to read papers about code can be off putting.
Surely the syntax is an incredibly minor part of it all?
> However code is really the lingua franca we use as an industry but in papers it is treated exactly as you say a nice addition.
Code is an implementation detail. Papers express ideas, not implementations.
>the first thing I want to know is what it actually does, step by step, at low level
I feel like we might be touching on some core differences between the top-down guys and the bottom-up guys. When I read low level code, what I'm trying to do is figure out what this code accomplishes, distinct from "what it's doing". Once I figure it out and can sum up its purpose in a short slogan, I mentally paper over that section with the slogan. Essentially I am reconstructing the higher level narrative from the low level code.
And this is precisely why I advocate for more abstractions with names that describe its behavior; if the structure and the naming of the code provide me with these purposeful slogans for units of work, that's a massive win in terms of effort to comprehend the code. I wonder if how the bottom-up guys understand code is substantially different? Does your mental model of code resolve to "purposeful slogans" as stand-ins for low level code, or does your mental model mostly hold on to the low level detail even when reasoning about the high level?
> i don't generally buy the argument that coding is drastically different from writing, insofar as it's laying out symbols in a way that can be understood (and followed) by another actor. that's a technical skill that's fairly transferable between the two
That's a great observation. A bit of a tangent, but I enjoy writing code with a tight feedback loop. Either with a debugger, a set of unit tests.
With writing, the feedback loop is not there. It's not clear whether the message achieves the desired effect.
Framing writing this way, explains why it's such a challenging activity. At least in my mind.
>> now after seeing how people verbally communicate programming concepts over the last decade and how that communication has impacted language design itself...I'm not so sure.
> the primary aim of programming is to have the programmers build a theory
I don't agree with that statement, but I don't think the primary aim is to produce a program either.
I believe the primary aim is to enable users to use a program. For that they need a mental model. Maintaining a consistent and simple theory among developers is a means to that end.
> I would rather program in such a way that I do not need (say) to examine the entire state of my code.
But if you could examine the entire state, why wouldn't you? People build correct intuitions by comparing their mental model to reality. If you don't ever show see reality, or only peek at it through sprinkled print statements, then it becomes harder to build an accurate mental model. This applies whether we are talking about a beginner trying to understand how pointers work or an expert grappling with a complex system.
Programming is always limited by our ability to comprehend complexity. So enabling simpler systems is a win, sure, but so is getting better at understanding things.
> they've trained themselves to look at a program and see the data structures rather than the code, and in my opinion that's a better way to think about a program.
I don't see how this is mutually exclusive to writing readable code. I'm not good at these but I picture good code in your definition to be utilizing data structures in an intuitive way instead of coming up with some novel but wacky performance trick.
I don't think so. In fact, I think this perspective is actively harmful.
A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the von Neumann execution of the program, or whatever else? These models are incidental. The thing that matters is whatever humans read and interpret and mentally model. And for the moment that's source code.
> Perhaps this seems a bit lazy, but I think of reading code as similar to reading books or articles: not everything is worth the same level of investment.
The point of reading code is to understand it. How to read code efficiently depends also on language and coding style. Which would require full blown IDEs just for proper code navigation. And honestly: If setting up an IDE for the language you want to read is too much trouble, programming is and therefore there is no need to read code at all.
EDIT: When I review code that reads like a book, the programmer immediately makes into my hall of fame. Such code is so rare that its coders should be paid their weight in gold - per hour.
> They almost convinced me somewhere in my career. But the hard truth I learnt is that most people are saying this because they aren’t capable of verbalizing what they are programming.
I'd say that's true, and it's worth noting at this point that expressing certain things in natural language is hard. The strict rules of programming languages mean that you can reason about programs to a complexity level that would otherwise be unreachable. Notation as a tool of thought. The corollary is that there may not be a simple natural language equivalent of the code you're writing, and that adding documentation might be more effort than it's worth.
> To succeed, programmers must reduce complex ideas to mental symbols that can be manipulated without articulation. It is hard to achieve this ability and painful to go in the reverse direction.
I wonder if I never achieved that ability, which is the reason that I pretty much always articulate coding ideas, in English, in my head. Maybe that's why I document so much better than other devs I've seen. ;p
It's sometimes obvious that it isn't the best approach to thinking through some things though. Cue paragraphs of explanation for a one line math formula.
>I think this is a very succinct and sensible way of viewing programming
I think it's a quite obvious way. To program a program you must know the program. To know the program you must know how to explain it. I mean you just formalized in a list of 3 points what's obvious to everyone: To build something you must understand that thing. Duh.
It's a bit of snobbery and elusive language to package this stuff up under the word "theory". Do we call construction workers masters of building and and construction theory? No.
>I don't think the word "theory" itself is important to the paper
It's the title of the paper. It's important.
> I really don't care about "legitimating" anything to do with programming.
Everybody cares about this. If everyone in the world thought programming was akin to doing crack cocaine you likely wouldn't be programming. Nobody admits this, everybody thinks they're above it, but the reality is nobody can be completely above it and the people who spend the most time thinking that they aren't influenced by "legitimacy" are the ones most influenced by it.
Naurs use of the word "theory" and trying to use at as an analogy to programming is an obvious attempt to raise programming to the level of "theory" as in "quantum theory" or "the theory of general relativity" because that's what people generally associate the word with.
His paper failed to raise programming to that level because Naur failed to even completely understand what a "theory" is and the difference between something like "color theory" vs. "Number theory". Instead Naur took a flawed definition that he felt would fit his purposes and used that. At best Naur basically described programming in a way where it's just another "color theory".
Why not just call the paper, "Programming is learning about the subject of the application you are programming."? Same thing right? No that title is to self evident and obvious. He needed to add some spice to the title and call it a theory.
I don't think the "spice" was misplaced. His explanation was the thing that was lacking here.
I'm saying programming is a step above that. Programming can be theory building akin to building things like "Electromagnetic Theory".
>I've always thought it'd be nice to be able to code at the speed of thought - you can often envisage the code or classes that'll make up part of a solution,
In my experience that 'solution' isn't a solution but rather a poorly guessed attempt at one single part of it. Whenever I've thought I have the architecture of a class all figured out there is one corner case that destroys all the lovely logic and you either start from scratch on yet another brittle monolith, or accept that you are essentially writing spaghetti code. At that point documentation that explains what does what and why is the only way to 'solve' the issue of coding.
> The whole point is not having to understand everything at once. And I would expect to understand what that particular line does to whatever level of detail I want by reading that line and recursively working backwards through the definitions of each operation invoked. Like clicking on each identifier and then doing ‘jump to definition’ in an IDE, instead of reading a book from cover to cover.
You regularly do that, using a tool built specifically to do that because it is close to impossible to read code without said tool. So are mathematicians just in need of better tooling?
> (And yes, this is why literate programming is a silly idea best forgotten.)
That style works pretty well for all other thought-transfer (i.e natural language)... are you sure it's a silly idea? or has the computers programmed us more than we have them?
> The problem with no/low code is it mirrors a DSL for whatever problem being solved. Anything more general becomes a programming language.
Yes! I've explored visually representing functions, and state machines, but it all feels very limiting compared to written language. I think more research could be done in the visual coding area for expressing thought, because I really want coding to look like something out of neon genesis evangelion--but IDK, written language isn't bound spatially. And in written language, it's so easy to express contradictions, which is an important part of developing a system. I think MC Escher is probably the most advanced research we have in the area of visually representing recursion and contradictions lol.
> because when you are reading you have to waste time thinking about why the programmer chose the set of features he did to write the code.
It seems to me that what Pike is getting at here is how easy it is to build mental models of the code, the language, the underlying system, down through all its layers, and, yes, the code's original author and any subsequent authors.
I share your frustration at the subjectivity of readability claims. There's actually starting to be good academic research on code readability, for instance this paper:
The hypothesis under Peter Naur's (the N on BNF) "Programming as Theory Building" paper is that transmitting (by talking) the mental model is far more important than other format of documentation to understand a system.
reply