> While the programmers lay in a functional magnetic resonance (fMRI) scanner, the researchers showed them snippets of code and asked them to predict what action the code would produce
I have a suspicion that writing code and understanding that written by someone else are different skill sets.
I don’t think this is about understand what is written, it’s about figuring out what that which is written means.
I’ve realized that I sometimes read code in more of a “story” mode, where I’m just looking for the gist of what’s happening and what it is “about” rather than the nuts and bolts of how it actually works.
It makes the code read more like a story from top to bottom.
Some like to organize their code such that any term always appears before it is used. Like a math proof or something. I find this somewhat pleasing but unhelpful for understanding the “story” you mention.
Maybe that’s just a photo of the crime scene.
If you look for cweb by itself, you might get weird results, because there are only so many four letter acronyms / words. Look for 'literate programming cweb' or just 'literate programming'.
Yes, it drives me nuts that e.g. Python makes you put the definitions before their use!
The one thing I'd say almost never works for reading code, though, is the thing people seem to insist is best practice: scattering everything into a hundred separate files with no clear order at all!
Trying to understand that code is like sitting down to an encyclopedia and then being asked to somehow use it to answer to the ultimate question of life, the universe, and everything.
The worst is when you grep the code for "main" in an attempt to at least come to your own idea of order, and it turns out that a bunch of files have their own main functions for various unit tests in files the build system just happens to ignore :/.
Given the strict formal requirements on order of languages like Pascal, Knuth had to come up with a clever preprocessing scheme to satisfy both the reader and the compiler. (See his tool, https://en.wikipedia.org/wiki/Web_(programming_system) )
Modern languages are a bit more flexible, but can still benefit from some re-ordering.
> The worst is when you grep the code for "main" in an attempt to at least come to your own idea of order, and it turns out that a bunch of files have their own main functions for various unit tests in files the build system just happens to ignore :/.
I used to use tools like grep a lot, but I found that my productivity really improved a lot when I set up an environment that supports 'jump to definition' and 'jump to references' etc.
> Python makes you put the definitions before their use!
Reading code without running it in your head feels like reading prose without actually comprehending it.
What you are referring to is simulating the execution in my head to figure out which execution flows exist, figuring out which cases aren't covered, what the function calls actually do, what the significance of those cookies is, etc. That's similar to how I read contracts. But unless I have to write a literary analysis or somebody asks me to find all the plotholes and inconsistencies I don't read normal prose that way.
It might be interesting if there are similarities between programmers tracing execution flows, lawyers reading an unfamiliar contract, and editors finding inconsistencies in short novels.
> predict what action the code would produce
So "this code looks at the pathname, then some cookies, and then either calls the signin function or returns True" seems to align with that.
It's also sometimes unnecessary to understand the high level picture of what the code does (like "oh, this computes the GCD using Euclidean algorithm, I had to code this in uni once")
So, most people read in a higher level fashion and understand just fine. It's really like reading math. When you read 23443 + 54454 * 454534, do you need to work out the computation to understand what this does?
A lot of code doesn't _do_ anything. And you can still read it.
Eg I'm thinking about type declarations, or constraint based programming, etc.
How could you run code, when you don't know the inputs?
You can reason through how the code could run with some example inputs, but that's just one of many tools we have in our belt to comprehend code.
In eg Rust or Haskell just looking at the types is pretty useful. Or in linear programming, you might want to think about the constraints expressed, but not actually do any arithmetic yourself.
Quoting again the part that that prompted the discussion:
> While the programmers lay in a functional magnetic resonance (fMRI) scanner, the researchers showed them snippets of code and asked them to predict what action the code would produce
The question wasn't about whether the programmers understood the code but whether they can predict what the code will output.
I hypothesize that either the programmer recognizes the purpose of the code or they don't.
If they do recognize, their brain will probably engage with the code differently, in a more high level way, taking into account the bigger picture; but if they don't they probably need to execute it step by step to have any chance of predicting what they do, which is akin to doing a calculation.
It also depends on whether the code is a tangled mess or well structured; how descriptive are function names and variable names; whether the code has comments; etc.
And of course in real world code there is a mix of both modes of reasoning. And the point is, those two modes of reasoning might as well activate different regions of the brain. (or maybe not?)
Well, it also depends on whether the suspect that the code has a bug.
Normally, we try to understand code by taking shortcuts through function names and structure, and fill the rest of in via pattern matching.
But if I suspect that a piece of code has a bug, I work hard to turn off these higher levels and concentrate on what's actually written.
I wasn't arguing here that any existing compiler shows a human level understanding of code. Just that there are many ways to understand code, and executing in your head is but one of tools in your arsenal.
Interpreters run your code, but they don't 'understand' it any better than compilers, which don't run your code.
In a sense, compilers typically 'understand' your code better, allowing them to do more optimisations.
(The boundaries in practice are more blurry.)
Here's an exercise for you: how much did Bill spend at the grocery store?
Bill and Tom went to the show store, and Bill bought a black pair of shoes for 23.56. Tom got a pair of red shoes for 40.30. Then they went to the grocery store, and Tom bought a loaf of bread for 3.50 and a gallon of milk for 5.99. Bill also bought a loaf of bread but didn't get any milk.
Anyone can tell that answering that specific question uses a different part of the brain than answering "what did tom and Bill do?"
And further uses a completely different part than: "modify the story to add a barbershop visit for Bill after the shoe store" which will require parsing the grammar to inject an extra story and keep things consistent.
Big picture !== Small details !== Writing !== Editing existing
The study feels incomplete if the four types of understanding are not being equivalently asked for both a story and the code.