https://code.kx.com/q/ uses words for a lot of things.
Instead of the APL ⌈/ you write 'max'. Instead of the APL ⌈\ you write 'maxs'. And so on.
Personally, I much prefer the APL for a few reasons.
If I tell you that +/ is sum, you can reasonably guess what product is. (×/).
However, in q, if I tell you 'sum' is sum, can you guess what product is? Well, maybe. But it's prd. Would you have guessed that first try?
This seems like it might not be that important, and obviously to the q developers it isn't. But it is a consideration that logically leads to terse symbols.
If you had to write reduce(plus, arr) every time of course you'd rather have a word for 'sum', it's only because of the symbols that let you decompose larger problems into the smaller primitives without ending up with more verbose code than other languages.
With modern day IDEs, auto suggestions would likely lead most developers to easily discovering the exact syntax for "product".
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.
> With modern day IDEs, auto suggestions would likely lead most developers to easily discovering the exact syntax for "product".
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...
To note is that, while it's easy to remember the word for sum/product/any/all/raze/max/min, you have to know that there's a word for it in the first place.
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!
in APL you have ~80 of such "pictographs" (and many you'd already know from regular maths). Sure, it's something you have to remember, but not much, really. Words can definitely help new english-speaking devs understand code, but, after getting used to the symbols, they just provide so much flexibility.
Personally, I much prefer the APL for a few reasons. If I tell you that +/ is sum, you can reasonably guess what product is. (×/).
However, in q, if I tell you 'sum' is sum, can you guess what product is? Well, maybe. But it's prd. Would you have guessed that first try?
This seems like it might not be that important, and obviously to the q developers it isn't. But it is a consideration that logically leads to terse symbols.
If you had to write reduce(plus, arr) every time of course you'd rather have a word for 'sum', it's only because of the symbols that let you decompose larger problems into the smaller primitives without ending up with more verbose code than other languages.