What you find 'annoying' I find about speeding up processing. I can 'pattern match' code far faster than I can read the text, so the alternative where I read every token is to dramatically slow down my mental processing of the code.
To me, reading every token is the functional illiteracy, the way only new learners spell their way through each word of a natural language.
I've never seen people make it to the point where they pattern match without being capable of reading the language properly.
I slow down and read everything when I need the details, the way I slow down when I read an unfamiliar word, or when I need to ensure I get every detail of a complex paragraph.
But most of the time reading at character or even word level is a waste of time. Unless you're dealing with a language like J or K etc. that doesn't lend itself to visual matching.
To me that is a fundamental problem with those languages.
But I get that people who program them tend to read token by token instead, and if that is what you want to do it needs to be compact.
> I can 'pattern match' code far faster than I can read the text
No you can't. You are getting the impression that you understand what the code does from its shape. This works only when the code does what you already assume it does before you start reading the code.
I very explicitly used pattern matching as distinct from reading because the entire point is that when you pattern match you don't need to understand fully what the code does.
It's a faster way to narrow down location in a code base, not removing the need from reading at all.
So you are expressing violent agreement even though you suggest "I can't".
Yes, it "only" works when the code matches my assumptions.
But that is most of the time.
On the few occasions I'm wrong I end up reading a bit more code than I otherwise would.
But overall I end up spending far less time reading code than if I didn't visually pattern match, because most of the time I only need to carefully read the pieces of code I need to understand the precise details of at that moment.
None of us ever read all the code we depend on and understand every aspect of it.
We depend on documented functionality and testing to ensure the pieces we don't have time to read - or access to - behaves how we expect, and otherwise code to deal with failures to conform. Reading everything and understanding it only works for tiny programs. Even then recognising patterns helps,the same way we don't spell our way through sentences.
What you are describing is the code-reading equivalent of skimming or speed reading. Yes, you can gain some information from it. At best you are going to miss things, at worst you will learn the wrong information. No one is saying "read all the code we depend on." What I am saying is that people do this for code they need to work on, or to review (because this is the only time most people ever bother to read code), which is why most people do such a poor job of understanding programs or spotting issues. Reading code by looking at its shape is a lazy acquired habit that is inappropriate in the most common code reading circumstances.
My view is pretty much entirely opposite of yours. The biggest problem I see with developers are developers who struggle to keep up because they don't know how to quickly navigate a code-base to understand the big picture, and end up bogged down reading way more than they need. Outside of languages designed to be read, lacking the ability to work by seeing structure is massively debilitating.
Meanwhile, I rarely if ever see people "reading code by looking at its shape", because recognizing code by shape doesn't tend to be something less experienced developers are any good at; if anything, caring about shape comes from caring about detail and wanting the detail to stand out. You need to be good at carefully reading code to be good at recognizing which aspect of the code matters and should stand out to be good at using code structure and shape as a tool to communicate.
> The biggest problem I see with developers are developers who struggle to keep up because they don't know how to quickly navigate a code-base to understand the big picture, and end up bogged down reading way more than they need.
That indicates a lack of a complimentary skill set involving cross-referencing tools, grep, and note-taking and diagramming. Similar to what you would do when trying to get an overview of a subject from books (citations, indexes, and diagrams and notes). Skimming by relying on code format reading is indeed a useless and counterproductive skill here, because you will miss the important details while wasting a lot of time. It is no surprise that you are seeing this in people if you and they think the cause and solution is a dichotomy between reading code and reading the code layout.
To me, reading every token is the functional illiteracy, the way only new learners spell their way through each word of a natural language.
I've never seen people make it to the point where they pattern match without being capable of reading the language properly.
I slow down and read everything when I need the details, the way I slow down when I read an unfamiliar word, or when I need to ensure I get every detail of a complex paragraph.
But most of the time reading at character or even word level is a waste of time. Unless you're dealing with a language like J or K etc. that doesn't lend itself to visual matching.
To me that is a fundamental problem with those languages. But I get that people who program them tend to read token by token instead, and if that is what you want to do it needs to be compact.