Edit: It probably would be useless to someone at all competent in APL and whose problems are more complex than their own failings.
What I have said matches exactly what another poster said about his experience in using a LLM with APL: "Its corrected code almost never works".
The LLM recognizes the problem that must be solved by the code, but it fails to generate the right APL symbol string.
I doubt that here a coding agent that attempts to verify the generated code by compiling it can help, because the LLM will generate eventually some syntactically-correct symbol string, but which will implement a different function than desired.
Only a complete feedback loop, with a battery of varied tests for the executable program produced by the generated code, which can verify if it really implements the desired functionality, can be used to filter the results for a working program.
APL is greatly superior to almost all programming languages that are popular today, for writing expressions involving arrays (this includes expressions that do not involve arrays in other languages, but which could be made simpler by using arrays in APL).
However, the original APL has defects, due mainly to the fact that it was an incomplete programming language, e.g. when compared to the other contemporaneous IBM language, i.e. PL/I.
What one needs is a programming language with modern program structures, data types and data type definition facilities, but also with an expression syntax matching the power of APL expressions.
The fact that in 2026 most programmers continue tho write "for" loops for handling arrays, instead of using array expressions like it was possible in 1966 in APL, 60 years ago, seems an aberration of history. Even in the 1966 PL/I one could use array expressions, even if only expressions that were much simpler than those of APL.
Using symbols instead of keywords, like in APL, is not cryptic for anyone who uses such a language regularly. It is cryptic for those who have not used them. The English-based keywords are somewhat less cryptic only for English speakers, and even for them they can be misleading before they learn their correct meanings.
This is a fascinating result. In some sense it’s like APL is actually the most human programming language, despite being one of the most difficult for ordinarily trained human programmers to pick up.
As an incompetent programmer who is far more comfortable with even the most experimental and abstract literature than any of the "easy" programming languages, I agree with this.
Edit: I was going to fix that sentence, but it is a good example of what thinking about programming languages does to my brain. The idea of a context free human language is alien, thinking in such absolute and concrete terms is weirdly abstract.
I had an introduction to APL in university and what I absolutely hated was this terseness. I guess when you're a mathematician APL is more natural but to me, as a programmer, I much prefer to have some extra verbosity to make my code more (human-)readable.
You can use a source preprocessor to enable you to write APL programs by using keywords instead of any symbols that you do not like. You can also use a source preprocessor to expand any traditional APL source, by converting symbols into keywords, so that it will be easier to read for you.
Using symbols instead of keywords is a minor feature of APL, which was inherited from the standard mathematical notation, from which APL was derived.
The important features of APL are the expression syntax and the set of available operators, not the symbols used for them.
Moreover, if you have difficulties in following complicated expressions, you can always break them in smaller subexpressions.
When someone presents an "incomprehensible" APL program, they show a huge expresion without comments.
A decent APL program, like in any other programming language, would need good comments, but here comments are frequently desirable at the level of subexpressions.
I guess that might be true for APL, for other programming languages that's not true at all. The ideal program is clear enough to be self explanatory. Of course there might be some implementation choices that need a comment. Or in some cases the problem is so difficult that this is not possible.
But readability should be the goal and most of the time this is feasible without comments. E.g. by using descriptive variable and function names. And by breaking up your program into logical and cohesive parts, using functions, objects, modules or whatever construct your language is offering.
That depends on what you're doing and who you expect to be reading your code, doesn't it? Sometimes what the human needs and what the computer/runtime needs are too far apart.
yes I agree. In case of APL, if your readers are mathematicians, I guess it could well be the language of choice.
And yes like I already said, self explanatory code is not always possible but more often than not it is. It just takes a little extra care and thought.
For someone who knows the APL symbols, what an APL expression does is self-explanatory. Someone who does not like symbols can replace them with keywords, that does not change the APL syntax.
The only problem is that you can write a very complex APL expression, which may be equivalent with a page of text in other programming languages. In such cases it is still easy to see what the expression does, but its purpose may be completely obscure, e.g. because you are unfamiliar with the algorithm implemented there, so you need comments explaining why those operations are done.
In many cases you can do like you suggest, you can split a very big expression in many subexpressions and store intermediate results in temporary variables to which you give names that are suggestive for their purpose, instead of adding comments.
However, I see this solution as inferior to just providing short comments for the subexpressions, which give you the same information as the intermediate variable names, but without forcing the compiler to choose an expression evaluation strategy that may be suboptimal.
kholis_ab•1h ago
abrudz•1h ago
jodrellblank•1h ago
ofalkaed•1h ago