4 ms·

Perhaps reading code activates the same arras as reading prose in English, but running code in your head activates other areas

Wowfunhappy 2y ago
If you read code and don't think about what it's doing, are you really "reading" it? Reading code without running it in your head feels like reading prose without actually comprehending it.
- evilduck 2y ago
  Maybe? I don’t need to read and calculate every iteration of some loop to understand that it’s mapping. While if I need to determine the actual output value of a function, I might.
- nextaccountic 2y ago
  Sometimes working out the details what is the right output of a piece of code (like, in the line x = f(15), is x 2345 or 2346?) is very time consuming 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?
- eru 2y ago
  > If you read code and don't think about what it's doing, are you really "reading" it? 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.
- usrusr 2y ago
  I'd put most of my code reading much closer to "inferring intention" than to "running in my head". It's really more like navigating through a complex building, looking for certain rooms than simulating execution. "running in my head" is to reading code like "pronouncing in my head" is to reading prose. Both aren't the norm.
- wongarsu 2y ago
  You can read (scan) code to get the general gist of it. It's more at the level of "this code looks at the pathname, then some cookies, and then either calls the signin function or returns True". That's about the same level where I read most prose. It's enough to answer the question "what does this do" (answer: "calls signin if you aren't logged in but should be") or "how complex is this" but not enough to modify the code or understand the intricacies of 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.
  - Wowfunhappy 2y ago
    But what participants in this study were actually asked to do is: > 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.
- martin82 2y ago
  You can read code line by line and understand what each line does, but any algorithm that has more than 5 lines of code probably needs an additional step where, after reading it line by line, you need to take a step back and think about it in a different way to understand what the whole block of code is trying to do.
bongodongobob 2y ago
Reading code and not running it is like reading a Spanish text but not knowing Spanish. Running it is equivalent to comprehension.
- eru 2y ago
  Compilers understand code pretty well, but they don't run it. (Similarly, if you are a human translating code from C to Pascal, you'll want to understand it, but you won't necessarily execute it by hand to get that understanding.) 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.
  - chongli 2y ago
    I’ve never seen a compiler that can answer the question: “what is the purpose of this function?” On the other hand, if I ask a human that question about a particular function and they are unable to answer it satisfactorily, I would have an extremely difficult time believing that they understand it.
    - eru 2y ago
      Sure, but your human doesn't necessarily gain that sense of purpose by executing the function in their head. More likely, they are looking at the name of the function and its arguments and return values first, and work from there. 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.
    - nextaccountic 2y ago
      Humans don't necessarily run the code step by step in their read to answer this question, either. 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?)

Wowfunhappy 2y ago

If you read code and don't think about what it's doing, are you really "reading" it? Reading code without running it in your head feels like reading prose without actually comprehending it.

evilduck 2y ago
Maybe? I don’t need to read and calculate every iteration of some loop to understand that it’s mapping. While if I need to determine the actual output value of a function, I might.
nextaccountic 2y ago
Sometimes working out the details what is the right output of a piece of code (like, in the line x = f(15), is x 2345 or 2346?) is very time consuming 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?
eru 2y ago
> If you read code and don't think about what it's doing, are you really "reading" it? 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.
usrusr 2y ago
I'd put most of my code reading much closer to "inferring intention" than to "running in my head". It's really more like navigating through a complex building, looking for certain rooms than simulating execution. "running in my head" is to reading code like "pronouncing in my head" is to reading prose. Both aren't the norm.
wongarsu 2y ago
You can read (scan) code to get the general gist of it. It's more at the level of "this code looks at the pathname, then some cookies, and then either calls the signin function or returns True". That's about the same level where I read most prose. It's enough to answer the question "what does this do" (answer: "calls signin if you aren't logged in but should be") or "how complex is this" but not enough to modify the code or understand the intricacies of 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.
- Wowfunhappy 2y ago
  But what participants in this study were actually asked to do is: > 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.
martin82 2y ago
You can read code line by line and understand what each line does, but any algorithm that has more than 5 lines of code probably needs an additional step where, after reading it line by line, you need to take a step back and think about it in a different way to understand what the whole block of code is trying to do.

bongodongobob 2y ago

Reading code and not running it is like reading a Spanish text but not knowing Spanish. Running it is equivalent to comprehension.

eru 2y ago
Compilers understand code pretty well, but they don't run it. (Similarly, if you are a human translating code from C to Pascal, you'll want to understand it, but you won't necessarily execute it by hand to get that understanding.) 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.
- chongli 2y ago
  I’ve never seen a compiler that can answer the question: “what is the purpose of this function?” On the other hand, if I ask a human that question about a particular function and they are unable to answer it satisfactorily, I would have an extremely difficult time believing that they understand it.
  - eru 2y ago
    Sure, but your human doesn't necessarily gain that sense of purpose by executing the function in their head. More likely, they are looking at the name of the function and its arguments and return values first, and work from there. 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.
  - nextaccountic 2y ago
    Humans don't necessarily run the code step by step in their read to answer this question, either. 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?)