Either way it takes time to consume the logic, but it's nice to have it all in one place than scattered about all over creation. I think that's what he's getting at with Aaron's more macro based view. He wrote thousands and thousands of loc before being able to whittle it down to such a terse amount. I can't read it, but that's less to do with APL and a lot more to do with knowing nothing of the domain of compilers.
The symbols actually make a lot of sense and can help you remember what they do. I can remember quite a few after only playing around with it a bit and reading a book on it ages ago.
For J, I read a good bit of "Numerical Programming in J" or something along those lines. I've found J to be more difficult than APL or K to pick up tbh. The tacit trains is just a bit too hard for me to follow.
> "They could choose symbols that don't look so ugly next to each other,"
Not as easily as you might think, given all the Unicode symbols exist because they already have a meaning to someone, and many of those might not render in typical font which computers already have installed.
You say "a symbol soup with multiple paragraphs explaining what the soup does and why it is good" - honestly, do you think people write multiple paragraphs explaining the code to beginners who can't read APL every single time they write any APL? Of course they don't! Your proposal relies on "symbol soup" being a fair and accurate description, which it isn't.
And, are you suggesting that people don't write comments explaining their code in common popular languages? Of course they do! (and should)
And, are you suggesting that people don't have to learn and practise to be able to read common popular languages when they learn to program? Of course they do, look at posts around the internet on people learning Java and Rust and C# and C++ and Python asking what some code means, what some syntax means, and not only beginners, lots of people ask like "I can code but what is this syntax?" and it's a Python generator comprehension, or a ternary operator, or a C# LINQ SQL style or a pattern match or an anonymous function or a compiler hint or a documentation generator template or a generic type or a turbofish or whatever thing they hadn't seen before in their previous languages or codebases.
And, are you suggesting that comments getting out of sync with code is only a problem in array languages? Of course it isn't.
Or that nobody ever complains about the readability of Java because it's so verbose and has so much abstraction you can't see what's supposed to be happening? People do. I do.
And as always, what about regex? It's so useful as a text processing language that it's often still shorter and cleaner to write a complex regex and paragraphs of comments explaining it, than to code the equivalent in classic string indexing and slicing and if/else branches. You'd end up writing a Greenspun-esque ad hoc, informally-specified, bug-ridden, slow implementation of half a regex engine.
That's not to say there is no criticism of APL's style possible, but if you want people to take the criticism seriously, have something new to say about it or some solid support and explanation for it. "Whenever you look at a problem somebody’s been working on for a week or a month or maybe years and propose a simple, obvious solution that just happens to be the first thing that comes into your head, then you’re also making it crystal clear to people what you think of them and their work." - https://exple.tive.org/blarg/2019/04/17/why-dont-you-just/
Which is better, compact or verbose code? That's a style issue and it all depends on who you ask. Verbose code requires you to read more. And more code to maintain.
Writing a mutex, or any number of distributed search/sort algos with disk io approaching dbs isn't. Network io isn't either is any natural sense