4 ms·

From the linked article, they found that it activates the region of the brain that carefully reasons through unfamiliar problems. They also speculate that this

From the linked article, they found that it activates the region of the brain that carefully reasons through unfamiliar problems. They also speculate that this might not generalize to people with 30 years of programming experience. Well, fine, a lot of academic research is done with students. But doesn’t that invalidate any comparisons with natural language processing, something that the test subjects do have decades of experience in?

jraph 2y ago
What I understand from this is that it could be that with 30 years of programming experience, the region of the brain that carefully reasons through unfamiliar problems activates less. That would make sense: if you are unfamiliar with programming, it makes sense that the unfamiliar problems zone activates. It would be interesting to study this, to know if this zone activates because of the unfamiliarity or if it still activates with experience while dealing with code. It could be that the zone will activate regardless (i.e. because when you are reading code, you are somehow always dealing with unfamiliar stuff - because this is why you are reading code in the first place usually) or not (i.e. because reading code is now familiar). > But doesn’t that invalidate any comparisons with natural language processing, something that the test subjects do have decades of experience in? It could: the test subjects would probably need experience in both natural language processing (which they have) and programming for the comparison to be fair. We most likely won't have "as familiar in both stuff", so we'll most certainly have to just do with "familiar enough with code".
- abcde777666 2y ago
  Anecdotally, looking at code written by someone else always goes to 'unfamiliar' territory. I can only read code I'm very familiar with like a book.
  - 8372049 2y ago
    Equally anecdotally, I mostly agree but have a friend who writes code much like I do. Reading his code is like reading my own.
BuyMyBitcoins 2y ago
I would be very curious to see what happens when the subjects are looking at a codebase they are familiar with. Even if there is some code within the repo they haven’t seen yet, the familiarity from style, convention, and knowing how the code fits into the rest of the program as a whole probably has a large impact as to how it is perceived.
rvense 2y ago
Maybe compare to second year students of a very foreign language... (Though I have to say, I'm a self-taught programmer with an academic background in theoretical linguistics as well as university-level experience of several languages quite different to my first language, and this result doesn't not surprise me. There are some obviously analogies to be made at some levels, I think the similarity between human languages and computer code is frequently overstated and a remnant from a more primitive linguistics that was quite narrowly focused on grammar.)
- thaumasiotes 2y ago
  > I think the similarity between human languages and computer code is frequently overstated It wouldn't even occur to me to think of them as belonging to the same category.
  - bborud 2y ago
    Occasionally you come across languages that do and, at least to me, those languages feel extremely difficult to deal with. For instance, I found AppleScript and HyperTalk to be awful to work with. I also notice that some junior programmers I've worked with tend to argue for coding styles in mainstream languages that read almost like sentences. Not sure if this is a generational thing or an experience thing.
    - codeflo 2y ago
      I’ve seen the same thing, it might be generational. Someone arguing that we need an isNotEqual(a, b) helper in addition to isEqual(a, b), because that’s supposedly “cleaner” and more readable than !isEqual(a, b). They were very vehement about it, but I don’t get that at any level. It’s more lines of code to write and maintain, more unit tests, more characters to type at the usage site and to me, reads exactly the same way.
      - utensil4778 2y ago
        For me, reading isNotEqual() introduces an extra mental variable. I have to spend extra effort to keep track of the bar over the statement that doesn't exist in the text. But that said, I see no reason that someone couldn't learn to parse notX as fluently as I parse !X. I suppose it's one of those fashions that change with the times. Probably a big reason that I stick to good old C a lot of the time.

jraph 2y ago

What I understand from this is that it could be that with 30 years of programming experience, the region of the brain that carefully reasons through unfamiliar problems activates less. That would make sense: if you are unfamiliar with programming, it makes sense that the unfamiliar problems zone activates. It would be interesting to study this, to know if this zone activates because of the unfamiliarity or if it still activates with experience while dealing with code. It could be that the zone will activate regardless (i.e. because when you are reading code, you are somehow always dealing with unfamiliar stuff - because this is why you are reading code in the first place usually) or not (i.e. because reading code is now familiar). > But doesn’t that invalidate any comparisons with natural language processing, something that the test subjects do have decades of experience in? It could: the test subjects would probably need experience in both natural language processing (which they have) and programming for the comparison to be fair. We most likely won't have "as familiar in both stuff", so we'll most certainly have to just do with "familiar enough with code".

abcde777666 2y ago
Anecdotally, looking at code written by someone else always goes to 'unfamiliar' territory. I can only read code I'm very familiar with like a book.
- 8372049 2y ago
  Equally anecdotally, I mostly agree but have a friend who writes code much like I do. Reading his code is like reading my own.

BuyMyBitcoins 2y ago

I would be very curious to see what happens when the subjects are looking at a codebase they are familiar with. Even if there is some code within the repo they haven’t seen yet, the familiarity from style, convention, and knowing how the code fits into the rest of the program as a whole probably has a large impact as to how it is perceived.

rvense 2y ago

Maybe compare to second year students of a very foreign language... (Though I have to say, I'm a self-taught programmer with an academic background in theoretical linguistics as well as university-level experience of several languages quite different to my first language, and this result doesn't not surprise me. There are some obviously analogies to be made at some levels, I think the similarity between human languages and computer code is frequently overstated and a remnant from a more primitive linguistics that was quite narrowly focused on grammar.)

thaumasiotes 2y ago
> I think the similarity between human languages and computer code is frequently overstated It wouldn't even occur to me to think of them as belonging to the same category.
- bborud 2y ago
  Occasionally you come across languages that do and, at least to me, those languages feel extremely difficult to deal with. For instance, I found AppleScript and HyperTalk to be awful to work with. I also notice that some junior programmers I've worked with tend to argue for coding styles in mainstream languages that read almost like sentences. Not sure if this is a generational thing or an experience thing.
  - codeflo 2y ago
    I’ve seen the same thing, it might be generational. Someone arguing that we need an isNotEqual(a, b) helper in addition to isEqual(a, b), because that’s supposedly “cleaner” and more readable than !isEqual(a, b). They were very vehement about it, but I don’t get that at any level. It’s more lines of code to write and maintain, more unit tests, more characters to type at the usage site and to me, reads exactly the same way.
    - utensil4778 2y ago
      For me, reading isNotEqual() introduces an extra mental variable. I have to spend extra effort to keep track of the bar over the statement that doesn't exist in the text. But that said, I see no reason that someone couldn't learn to parse notX as fluently as I parse !X. I suppose it's one of those fashions that change with the times. Probably a big reason that I stick to good old C a lot of the time.