(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.)
It wouldn't even occur to me to think of them as belonging to the same category.
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.
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.
The exception, imo, is functions that take boolean arguments. Languages should make it easy to show what they mean, and devs should take care to explain them.
sort(reverse=true, numeric=false) is much easier to read than sort(true, false).
(Silly example, it's meant to illustrate the general point, not to say anything about the signature of a sort() function.)
Then on the opposite end of the spectrum wrt new things, we have Rust, which comes off to me as pathologically terse and inscrutable - certainly much more difficult for a newbie to parse than SQL.
Unwrap a loaf of bread
Pull out two pieces
Put them side by side
Spread peanut butter on the left one
Spread jam on the right one
Etc.
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".