They're all macros to make common operations more compact

I read the J Incunabulum before encountering this, and the point that stands out is that you don't start by jumping into the middle of it like many programmers who are familiar with C will do; the macros defined at the beginning will confuse you otherwise. They also build upon previous ones, so the code ends up climbing the "abstraction ladder" very quickly. I personally like the Iterate macro (i), for how it compresses a relatively verbose loop into a single character; and of course in an array language, the iteration is entirely implicit.

In other words, I believe the reason this code is hard to read for many who are used to more "normal" C styles is because of its density; in just a few dozen lines, it creates many abstractions and uses them immediately, something which would otherwise be many many pages long in a more normal style. Thus if you try to "skim read" it, you are taking in a significantly higher amount of complexity than usual. It needs to be read one character at a time.

As someone who has spent considerable time working with huge codebases composed of hundreds of tiny files that have barely any substance to them, and trying to find where things happen becomes an exercise in search, this extreme compactness feels very refreshing.

>In other words, I believe the reason this code is hard to read for many who are used to more "normal" C styles is because of its density; in just a few dozen lines, it creates many abstractions and uses them immediately, something which would otherwise be many many pages long in a more normal style.

I also spent some time with the Incunabulum and came away with a slightly different conclusion. I only really grokked it after going through and renaming the variables to colorful emojis (https://imgur.com/F27ZNfk). That made me think that, in addition to informational density, a big part of the initial difficulty is orthographic. IMO two features of our current programming culture make this coding style hard to read: (1) Most modern languages discourage or forbid symbol/emoji characters in identifiers, even though their highly distinctive shapes would make this kind of code much more readable, just as they do in mathematical notation (there's a reason APL looked the way it did!). (2) When it comes to color, most editors default to "syntax highlighting" (each different syntactic category gets a different color), whereas what's often most helpful (esp. here) is token-based highlighting, where each distinct identifier (generally) gets its own color (This was pioneered afaik by Sublime Text which calls it "hashed syntax highlighting" and is sometimes called "semantic highlighting" though that term was later co-opted by VSCode to mean something quite different.) Once I renamed the identifiers so it becomes easier to recognize them at a glance by shape and/or color the whole thing became much easier to follow.

When you zoom out on Google maps, usually the street names and bussiness pins disappear. This code style is like having a fully informationally dense zoomed out map. Being too zoomed in is definitely frustrating, and reminds me of early attempts at "mobile" web pages. But I'm not sure that this condensed code style is a good general solution either, it certainly seems overwhelming, like a where's waldo puzzle.

I prefer having a consistent information density regardless of zoom level. When I would like to see more details, I would like to achieve that by zooming in. When I want the overview, I'd prefer to zoom out and have certain details omitted from the map.

Having a clear and by-convention code organization is one way to achieve this. Then to drill into the details, just navigate the project directory to the right file.

For rabbit Hole style hunting, following references/symbol usage/definition is ideal, which is enabled by modern IDEs.

K and family are made for data analysis. Data analyses are relatively simple software projects that don't have a very wide scope. I think this dense style of programming falls apart when you consider the breadth of requirements of typical modern application software.

"... trying to find where things happen becomes an exercise in search."

It seems like developers actually prefer large codebases and having to use recursive search through multiple layers of sub directories

I prefer no sub directories and being able to just grep against *.[ch] with no recursion

I think projects in Java languages are the worst when it comes to having to search through numerous small verbose files having barely any substance to them. IDEs probably make this easier but I don't use one

Years ago I read that Whitney's "IDE" is something like the Windows console and Notepad. He has said in interviews that he wants all the code to fit on a single page

Adding some comments would have been advisable, but I guess he doesn’t need comments.

APL taught me the importance of comments - if I didn’t comment my code thoroughly I would forget how it works and what it did as soon as I moved away from the keyboard. It is a cruel language.