Stages of denial in encountering K

How many times have you opened a Java/C#/C++ project and opened up class file after class file trying to understand how the whole thing is pieced together, faced with a monstrous system and, days later, still no understanding of how the system works at a macro level and how everything is connected.

How many times have you started browsing a GitHub repository looking for where something is implemented, opening file after file only to give up an hour later with absolutely no understanding of the organization of the system or being able to predict where any particular functionality is implemented.

Most people would say Python is a fairly legible language. You can write a class or function and most programmers can understand how it works fairly easily. However, with Python (or any mainstream language) you are only looking "down". You see what the function uses and how. You cannot see how the function itself is used. The other part of a function's meaning is how it's used idiomatically and what problems are solved by it. This is why, when figuring out how to use a library, most people prefer to look for an example than to browse the code. I believe any codebase of sufficient size effectively becomes a sort of library for solving its specific problems in its specific ways. There is a sort of hierarchy of increasing domain-specificity from language to library or framework to codebase, where each level has its own idioms and preferred ways of doing things.

Even ignoring the seemingly unnecessarily obtuse notation (which you really do get used to reading, but I recognize it's a hard sell to say "use it regularly for a few weeks/months and it'll all be perfectly clear trust me"), K (and J, and APL which I'm more familiar with) are legible in a way that other languages are not. When the entire system fits in a page of code you can understand everything about it from the top down. APL allows you to look "up". From any function you can see, instantly, without endless scrolling and switching between dozens of files, everywhere the function is used and how and what functions it's used in conjunction with. You do not need to press "switch to header file" ever. You do not need to press "go to definition" ever. The definition is right in front of you. Often since APL prefers idioms to building giant towers of abstraction, the definition is the name.

Not using "for" loops is not really the point of APL. The point of APL is that being really, incredibly, seemingly unnecessarily concise fundamentally changes how you read code.

APL is very legible.

It mocks it, but it doesn't present a convincing argument. Switching from an imperative language to K is making several changes at once, so we can't really conclude anything about the details of which changes are good or bad. The closest I've seen to a controlled experiment is something like: on a Haskell codebase, switch between using symbolic names like "^>>" and alphabetic names like "promap". And my experience has been, in a real-world mixed-ability team, that overall the alphabetic names had the advantage; if this isn't so for K, then we should try to understand the reasons why. The OP gestures at this, but unconvincingly: why yes, "ordinal" is much clearer than "I'm very much a believer in concise notation (more than most people I've worked with), but the advantages of having a name that can be unambiguously spoken are large enough to outweigh a small constant factor. I sketched a mainstream-FP implementation of the famous 1-liner APL game of life, which became something like three lines (not counting implementing the equivalents of the APL operators, which require slightly fancy polymorphism to do the right thing on vectors and matrices but are otherwise not that special) that could actually be read and talked about. That seemed like a good tradeoff.

One can - and should - write code that's much denser than the current maintstream style. I do think the industry massively underestimates the value that comes from fitting a function or class on a single page. But I remain unconvinced that it's worth going all the way to code that can't be communicated verbally.

There simply aren't enough professors to maintain that breadth of courses in those departments.

I don't believe this holds up to scrutiny. APL as a language was made to be spoken, and it seems to have succeeded in that. Alan Perlis briefly touched on that in a great paper,[1] and just about everyone who's worked with the language and its derivatives agrees that your statement isn't true.

The idea that APL and its derivatives can't be "read and talked about" is frankly ignoring reality by any stretch of the imagination.

For example, here's [2] [3] [4] some videos disproving your statement, the first two being APL, the last being k itself.

For extra bonus points, see Aaron Hsu's talks [5]; pick any of them, they're all pretty good, and most have a segment in them explaining how that viewpoint is wrong.

[1] https://www.jsoftware.com/papers/perlis77.htm

[2] https://www.youtube.com/watch?v=a9xAKttWgP4

[3] https://www.youtube.com/watch?v=DmT80OseAGs

[4] https://www.youtube.com/watch?v=kTrOg19gzP4

[5] https://www.youtube.com/results?search_query=aaron+hsu