| ▲ | In Praise of APL (1977)(jsoftware.com) |
| 34 points by tosh 3 hours ago | 21 comments |
| |
|
| ▲ | runeks 34 minutes ago | parent | next [-] |
| I find APL very difficult to read. Incidentally, I am told (by stack overflow) that the APL expression "A B C" can have at least four different meanings depending on context[1]. I suspect there's a connection here. [1] https://stackoverflow.com/a/75694187 |
| |
| ▲ | skruger 21 minutes ago | parent [-] | | Yes, it's either an array (if A, B and C are arrays), a function derived via the dyadic operator B, with operands A and C being either arrays or functions, a dyadic function call of the dyadic function B (A and C are arrays), or the sequential monadic application of functions A and B to array C, or a derived function as the tacit fork (A, B and C are functions). Did I miss anything? | | |
| ▲ | yvdriess a minute ago | parent | next [-] | | And they could be 0- or 1- indexed? :P | |
| ▲ | abrudz 11 minutes ago | parent | prev [-] | | Yes, it can also a fork where A is an array while B and C are function and a tacit atop where either B is a monadic operator and A its array or function operand or A is a function and C is a monadic operator with B being its array or function operand. Finally, it can be a single derived function where B and C are monadic operators while A is B's array or function operand. | | |
| ▲ | boxed 2 minutes ago | parent [-] | | Do APL programmers think this is a good thing? It sounds a lot like how I feel about currying in language that have it (meaning it's terrible because code can't be reasoned about locally, only with a ton of surrounding context, the entire program in the worst case) |
|
|
|
|
| ▲ | singularity2001 2 hours ago | parent | prev | next [-] |
| Should be the ultimate final incomprehensible programming language for code agents |
| |
| ▲ | ofalkaed 2 hours ago | parent | next [-] | | ChatGPT is pretty good at correcting my mistakes. Give it a snippet of not quite working code with no explanation and it almost always correctly identifies what I am trying to do and explains where I went wrong. Its corrected code almost never works but its explanation of why my code failed gets me my answer and that is what I really want. A year ago it could not help me in the slightest, it has improved quite a bit. The biggest issue with AI and APL seems to be that it does not quite understand the differences between the various versions of APL and seems to view APL2, Dyalog and GnuAPL as all the same language. Edit: It probably would be useless to someone at all competent in APL and whose problems are more complex than their own failings. | |
| ▲ | adrian_b 2 hours ago | parent | prev [-] | | True. Due to its lack of verbosity, APL is not at all forgiving for any substitution or transposition in its symbols, which can cause great differences in program output, so it is quite improbable for LLMs to generate a working program, unless it is identical with one from its training set. 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. | | |
| ▲ | pavlov an hour ago | parent | next [-] | | > “it is quite improbable for LLMs to generate a working program, unless it is identical with one from its training set” 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. | | |
| ▲ | ofalkaed an hour ago | parent [-] | | >it’s like APL is actually the most human programming language 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. |
| |
| ▲ | skruger an hour ago | parent | prev [-] | | Whilst LLMs still perform weakly in APL, the situation is improving at pace, and giving it a “skill” to evaluate code makes a dramatic difference. I gave a conference talk about it recently (video): https://youtu.be/H_wdKeJ8gt4 |
|
|
|
| ▲ | misja111 2 hours ago | parent | prev | next [-] |
| > The virtues of APL that strike the programmer most sharply are its terseness — complicated acts can be described briefly, its flexibility — there are a large number of ways to state even moderately complicated tasks (the language provides choices that match divergent views of algorithm construction), and its composability 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. |
| |
| ▲ | adrian_b an hour ago | parent [-] | | Terseness is easier to remove from a programming language than verbosity. 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. | | |
| ▲ | misja111 an hour ago | parent [-] | | > 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. | | |
| ▲ | adrian_b an hour ago | parent | next [-] | | What you say about readability is right, but it is something completely orthogonal to the syntax of APL expressions. All those things can be done in any language that uses the APL expression syntax. 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. I completely agree that "The ideal program is clear enough to be self explanatory". However, regardless of the programming language, it is very frequent to see programs where it is clear what is done, but you cannot understand why that is done. In most cases you already have precise expectations about what the program should do, but you see that it does something else, without any apparent reason. In many cases, the program does certain things because there are certain corner cases that are not at all obvious from the existing system documentation, or worse they are not documented at all anywhere, except for the presence of a mysterious program section that handles them. Even worse is when such mysterious program sections are present only because of some historical reasons, which are no longer true, and now the code is superfluous or even harmful. These frequently encountered situations can be prevented only by adequate comments about the purpose of the code, regardless how self-explanatory is what it does. | |
| ▲ | creata an hour ago | parent | prev | next [-] | | > The ideal program is clear enough to be self explanatory. 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. | |
| ▲ | misja111 an hour ago | parent | prev [-] | | @creata: 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. |
|
|
|
|
| ▲ | kholis_ab 2 hours ago | parent | prev [-] |
| i love APL, but never ever tried it ... only watched videos of code_report |
| |
