3 ms·

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?)
    - eru 2y ago
      > 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. 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.
eru 2y ago
> Running it is equivalent to comprehension. 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.)

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?)
  - eru 2y ago
    > 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. 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.

eru 2y ago

> Running it is equivalent to comprehension. 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.)