It is an interesting observation. I expect it is the difference in expertise though. The author compares reading code snippets in Dr. Dobbs (which dates them probably 10 or 15 years ago) to reading stories.
Here is the thing, everything you read in a story is supposed to convey imagery of things like what you may have already experienced, they are already internalized, you "see" them when you read as if you were there.
Allow me to use another popular space as an example, music. When you are first reading sheet music, you see notes on a stave, key signatures, different shapes representing different durations. At first you mechanically take that understanding and laboriously turn it into actions on your instrument. But after a while, if you do it enough, the shapes become recognizable as rhythms, the tones in the staves become tones not symbols, and then you stop "reading" music, you look at it and you can hear what it will sound like. And by that time you can make your instrument do what ever you hear.
Coding is not entirely different, at some point you don't see syntax, you see algorithm, you see inter-relationships of data structures, you see flow. After a number of years of coding I got to the point where I could see what code was doing pretty easily (except for obfuscated code which is always jarring on first look). I stop seeing code loops and start seeing iterative processing, if statements are branches on a path.
Anything in words or symbols, is code for something else. Whether its a murder mystery, a symphony, or a sorting algorithm the words and symbols are there to express the idea inside your head you can understand it, I think it is all reading though :-)
Code is, however, considerably more tree-like than stories or sheet music. Sheet music has something resembling minimal control structures, to be sure, and there are examples of kinds of stories that are more non-linear than usual (and are usually considered mind-benders for that reason).
I think that's what the GP is getting at. Even with domain knowledge, really understanding a code almost always requires diverging into other parts of the 'text'. You can defer it if your thought process is structured enough, but you still have to do it eventually.
Yes, once you know more about a domain, you see larger, more organized chunks when you look at data in that domain. There were studies that showed how amateur Chess player see individual pieces where Chess masters see piece-arrangements. Etc.
I would still say that programs are quite different from any natural language text in that they require a sustained effort to learn "what really happens here" as opposed to "what general kinds of things are being done in the different parts of the program".
A murder mystery is a genre where "one little detail" often is where the whole direction of the story is said to go. But that's usual a single discreet gotcha, added for theater. A program often consists entirely of such things, added not for theater but because computation can't help but work that way.
I've got the book 'Learn you a Haskell for great good' and I've gone through it. But to be honest I've I have always resonated more with structural languages than functional ones.
LYAH is slow and doesn't communicate the compelling parts of Haskell at all. There is no functional/structural dichotomy. Structural isn't a category of programming languages. There are no programs without structure. You may be mistaking syntax ( {} blocks vs. s-expr ) for having something to do with semantics.
It's also possible somebody has told you Haskell is a declarative language a la Prolog. It is not.
This feels very much like the original motivation for design patterns - raising the level of communication and recognition. It's shame that patterns were largely sneered at as stating the obvious, when that was sort of the point.
The difference is you don't read sheet music to look for errors (tonal imbalance, wrong notes, what have you), you play it and listen if it sounds "right".
Much the same you can't read code (code review) to look for errors, you'll miss most. You need to run and test the code to really find the errors.
Here is the thing, everything you read in a story is supposed to convey imagery of things like what you may have already experienced, they are already internalized, you "see" them when you read as if you were there.
Allow me to use another popular space as an example, music. When you are first reading sheet music, you see notes on a stave, key signatures, different shapes representing different durations. At first you mechanically take that understanding and laboriously turn it into actions on your instrument. But after a while, if you do it enough, the shapes become recognizable as rhythms, the tones in the staves become tones not symbols, and then you stop "reading" music, you look at it and you can hear what it will sound like. And by that time you can make your instrument do what ever you hear.
Coding is not entirely different, at some point you don't see syntax, you see algorithm, you see inter-relationships of data structures, you see flow. After a number of years of coding I got to the point where I could see what code was doing pretty easily (except for obfuscated code which is always jarring on first look). I stop seeing code loops and start seeing iterative processing, if statements are branches on a path.
Anything in words or symbols, is code for something else. Whether its a murder mystery, a symphony, or a sorting algorithm the words and symbols are there to express the idea inside your head you can understand it, I think it is all reading though :-)