Sure. I don't doubt this. However, if your language is good enough, it's unnecessary. I don't want to rely on an IDE for something as straightforward as taking the product of a list of numbers.
> words that describe the inherent function makes reading the source A THOUSAND TIMES easier
If your functionality is complicated, this is probably true! No one's saying not to use descriptive function names in APL. You absolutely can (and probably should) for things used multiple times more complicated than a couple of symbols. However, in general I don't think this is true. Have you tried?
With regards to guessing the meaning, you do have a good point. If you show someone some APL, and they've never seen it before, it will most likely be completely unreadable, unless they've defined some sort of custom DSL. It doesn't mean they can't pick it up though.
Comparing q and APL again, if I see the word 'raze' in q, without knowing what that is already (looking at docs etc) it's basically impossible to guess. In APL, that would be ,/ instantly readable as 'reduce by concatenation'.
> it's just one more thing that I have to remember
Yes, you'll have to remember the symbol for reduce. But you won't have to remember the word for sum, product, any, all, raze, max, min...
Seems worth it to me!
In contrast, in APL, once you know about reduce, there's just one way any of those could be written, and it's obvious. And after you learn about scan (cumulative reduction), you also know the cumulative version for all of those!
Hover over the characters at the top to get a sample of a couple ways it might be done.
Additionally, words that describe the inherent function makes reading the source A THOUSAND TIMES easier.
If A new developer sees the word max/min/sum, they can almost assuredly guess the meaning versus a random pictograph. And even after learning that ‰ means reduce (for example), it's just one more thing that I have to remember.