Coincidentally, the author of this article writes code and does math mentally in Cantonese (because you can store more in your head at one time in Cantonese than you can English), so your CJK comment might be closer than you'd think.
However, APL is pretty simple. There are a lot of resources for J that are made for beginning programmers, and APL requires a different mindset than ALGOL derivatives. Try glancing at these:
If you really want to get a pure conception of APL, though, try the book it's named after: A Programming Language. Or Notation as a Tool of Thought (here's a semi-well-digitized copy: https://www.jsoftware.com/papers/tot.htm).
APL is generally readable, however a common mindset that if you come back to it in a day, a month, a year or a decade, it's faster to rewrite it than to try to figure out what you were thinking: if you can't understand what it's doing, you must have done it wrong the first time.
For me it seems that the big disconnect is between people who read code vs. people who pattern match code.
I never read a piece of code start to finish to understand it - I glance at it and expect to see patterns, and then explore based on pattern recognition. I only read details piecemeal.
That doesn't work if there are no clear visual patterns, and I'm extremely picky about syntax and layout of code as a result, not for the code to be readable, but on the contrary, for it to be possible for me to glance at a piece of code and have intuitions about it from seeing shapes of code layout laid out spatially.
I'm not sure if there are reasonable ways of reconciling those two ways of looking at code.
In my experience working with other programmers, it is very common for people to only learn to visually pattern match on code formatting and stop there. This is the code reading equivalent of functional illiteracy. Using = instead of ==, missing break statements, all kinds of semantically significant mistakes become completely invisible when you look at the shape of the code instead of reading to see what it does. In my experience, people who can only read code by visual layout do very poor code reviews.
Another annoying thing, as you point out, is that this makes people hung up on code formatting style to an unreasonably extreme degree. People who only learn to look at the layout literally cannot "read" an unfamiliar layout, which tends to frustrate them, and in a lot of cases seems to hurt their ego, because their conception of themselves as competent programmers is challenged.
The way to "reconcile" that is to learn to read code for its meaning.
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.
However, APL is pretty simple. There are a lot of resources for J that are made for beginning programmers, and APL requires a different mindset than ALGOL derivatives. Try glancing at these:
https://code.jsoftware.com/wiki/Books/Beginners
If you really want to get a pure conception of APL, though, try the book it's named after: A Programming Language. Or Notation as a Tool of Thought (here's a semi-well-digitized copy: https://www.jsoftware.com/papers/tot.htm).
APL is generally readable, however a common mindset that if you come back to it in a day, a month, a year or a decade, it's faster to rewrite it than to try to figure out what you were thinking: if you can't understand what it's doing, you must have done it wrong the first time.