I do not agree. I have never used an APL interpreter or compiler, but nonetheless I use it as a pseudo-code, so instead of no one, there is at least one user.

Whenever people claim that APL is write-only they give some convoluted example with a bunch of obscure APL operators that are seldom used, so even for APL users it might be difficult to remember what they do.

For the majority of the problems that a programmer might need to solve every day, only a small fraction of APL might be needed, which is simple to understand, learn and remember.

As an unfamiliar notation, you might need to learn 5 or 6 extra operators at most and for the rest you need just use the same that you use in any programming language only with additional rules that allow more freedom than in the popular programming languages.

The main difference between APL and conventional languages is that you no longer have to write "for" loops, you just write the same expressions that you would write for scalar variables.

I cannot see how one would claim that omitting all the redundant boilerplate code needed by "for" loops or "map" functions decreases the readability of a program.

If you do not want to learn 20 new operators, there is no need for that, the base APL language does not need them. There are only very few operators that are strictly needed, e.g. reduction, inner product, outer product, rank, index.

If you like verbose identifiers you could use names for them, the symbols are not the essence of APL, only its rules for writing expressions.

The 3 simplest rules are:

1. a function of 1 argument applied to an array is the array of the values obtained by applying the function to the array elements.

2. a function of 2 arguments applied to a scalar and to an array is the array of the values obtained by applying the function to the scalar and to each array element.

3. a function of 2 arguments applied to 2 arrays of identical ranks and dimensions is the array of the values obtained by applying the function to each pair of corresponding array elements.

I do not see anything obscure and unintuitive in such simple rules. (It should be obvious that these are particular cases of a general rule that in a function of N scalar arguments, you should be able to replace 1 or more of the scalars with arrays of the same rank and dimensions and then the function result shall also be an array of the same rank and dimensions.)

On the contrary I find it hard to understand why these rules are not valid in any programming language and you are forced in most of them to write loops for such trivial operations.

There is only one real barrier for using the APL notation, but in my opinion those who surpass it are rewarded.

The order of evaluation for APL expressions is different from the order learned in school, which is then extended in various way in the programming languages.

In APL there are no precedence levels. The right operand of an operator is everything that is to the right, until the end of the expression.

So the operators are evaluated from the right to the left (i.e. in reverse order compared to the traditional order for e.g. addition), unless you use parentheses. This order is frequently more readable than the traditional, because usually when browsing a program you do not need to read the expressions until their end. The important parts are at the left end and it is normally enough to read only those. With the traditional order you might need to scan the line much farther to the right to be sure that you did not miss something important.

This obstacle of the different evaluation order discourages many of those who could benefit by using APL as a pseudo-code, but once you understand that this modified order can really simplify most expressions and you become adept at reading it as easily as the traditional order, you can use APL as a pseudo-code with good results.