It always felt strange to me that the main implementation of something as niche and esolang-adjacent as APL is neither OSS nor casually usable commercially, but instead comes under an enterprise license.
Anyway, I had a fun time a while ago translating APL programs to NumPy. At some point you get what APL is all about, and you can move on with life without too many regrets. Turns out most of the time it's more like a puzzle to get an (often inefficient) terse implementation by torturing some linear algebra operators.
If you're after a language that's OSS, has terse notation, and rewires your brain by helping you think more clearly instead of puzzle-solving, TLA+ is the answer.
Edit: if you're curious to see at a glance what APL is all about:
APL code:
(2=+⌿0=∘.|⍨⍳N)/⍳N <- this computes primes up to N and is presented as the 'Hello world' of APL.
Thanks for the response. I'd interpret it as a valid technical caveat, but it feels somewhat orthogonal to what I was pointing out.
You focus on the 'often inefficient' parenthetical, yet, to me, your response highlights the puzzle nature of the thinking APL encourages. If anything, it shifts the question from 'how do I express this tersely' to a still narrower 'how do I express this tersely in a way the interpreter can also optimize'.
I think every programming language to a degree has some kind of puzzle aspect
I'm not sure APL has more or less of it compared to other languages
for example in Python, even though the language has a concept of "There should be one-- and preferably only one --obvious way" (PEP 20) it is quite multi paradigm, which I think is a strength of Python
oop, functional, imperative, …
and you get tons of libraries to choose from
e.g. numpy, pandas, polars, pytorch, keras, jax, … etc
but you still also have to figure out the algorithm and data structures you want to use (like in any language)
and you also kinda want to know (if you care about performance) how pytorch differs from numpy and how that differs from using a list with boxed values
Not saying this is not the case with APL
it definitely helps if you are familiar with the APL implementation you're using if you care about performance
I just don't think it's a disadvantage of APL over other languages
Agreed. I think I shouldn't put hard boxes around languages like 'puzzle language' vs 'abstraction/clear thinking language'.
What I was trying to point at was more specific: the way I experience APL thinking tends toward 'expression search' and 'notation compression', which feels, to me at least, somewhat at odds with clarity about the underlying problem. More often than not, I seemed to produce an APL-shaped model of the problem rather than a problem-shaped model expressed in a language.
When I first learned about APL, I was looking for new ways to think about computation. What I found was a language that rewarded deciphering APL programs and generating clever new ones. That is interesting and beautiful, but it was not quite the kind of brain-rewiring I was looking for. My original comment was targeting people in a position similar to mine and trying to set expectations about what they would learn best from APL. APL may change how you think about array expressions and how far they can go, but TLA+ is much closer to what I'd recommend if what you want is clearer thinking about programs, systems and state.
> At some point you get what APL is all about, and you can move on with life without too many regrets.
Unfortunately, this seems to be a common experience. A lot of smart people only engage with APL via toy puzzles, like you did, and bounce off because that gives no insight about how to use the language in real life. IME, to really start getting APL you need to write and rewrite a full application 20 times.
It helps to read code from the masters, too [0, 1, 2, 3, 4]. These all approach architecture in different ways: pedagogical FP style, OOP heavy, data-oriented design, event-driven state-machine, or a mix of the above.
> As you can see, the famous prime generator is not even the Eratostenes' sieve, but a simple N^2 divisor counting computation.
Well, that's because you wrote a divisor function, not a seive. Arguably, the ease of typing an outer product (i.e ∘.|⍨⍳N) can tempt us into writing quadratic algorithms unnecessarily, but this is just an experience issue, IMO.
If we want a seive, we can just write one directly:
p⊣{ω~n×1+⍳⌊N÷p⍪←n←ω↑⍨1⌊≢ω}⍣≡1↓1+⍳N⊣p←⍬
The algorithm is O(N log log N) as expected of a naive Eratosthenes implementation. You'll need ⎕IO←0 if you want to try it out.
There's also a faster seive by Roger Hui [0] in the dfns workspace as well as a family of prime number functions [1] for things more than just prime generation.
That's not O(N log log N), it's more like N^2. Prime sieves are hard to implement well with immutable arrays for obvious reasons; there are some cool methods but they're definitely harder. I'm ashamed to be part of a community that won't cop to this.
The algorithm iterates over numbers ⍺ from 2 to N, removing the multiples that are greater than ⍺ and no greater than N from p. If the removal with ~ has to inspect all of p, then all the primes are there so we have asymptotically at least N/log N entries by the prime number theorem and we get N^2/log N time (when ⍺ is over N/2, no multiples are in range so this can be skipped, but that just cuts a constant factor 2 from the time). Conceivably p could be marked sorted, so the entries to remove could be found with a binary search. This is a bit harder to analyze, but I think each prime under √N will cause the list to change, and incur N/log N data movement. So you get at least (N/log N)^(3/2) cost, still quite a bit worse than linear.
Edit: changed the algorithm while I was writing... the new one is better, it keeps one list p of primes and one list ω of not-yet-marked-out numbers. However, primes are removed from ω one at a time, so that each of the N/log N primes has to be moved for each one before it, giving at least (N/log N)^2 cost (I mean, maybe an interpreter could binary search and also recognize when ~ only drops the first entry and do that by slicing? But the (N/log N)^(3/2) from above definitely holds). Mutating a bit array in place is pretty important to classical sieve performance.
Eep. You're right. Evidently, I didn't even know what a sieve was in this context and wrote a search instead. You got me to do a bit of research. Actually, this discussion is exactly where I think APL shows one of it's strengths. It feels like a human communication tool more than any other PL I've mucked about with. The hard parts here are not language issues but fundamental understanding ones.
It's a tad tricky to carefully analyze the asymptotics of my above prime generator, since the search space of Without (~) shrinks on each iteration. I think Merten's theorem gives an estimate of e^-γ/log(p_i), which we need to sum for all primes up to N. Taking prime density 1/log(n) and integrating N/(log x)^2 over our range is O(N^2/log N), I think.
> Mutating a bit array in place is pretty important to classical sieve performance.
It's possible to get O(N^(3/2)/log N) in an ordinary interpreter with some changes to the code, assuming linear-time ~ with hashing. The idea is to leave the primes in ⍵ and stop when it stops changing, which will happen at the first prime over √N. To get the complexity multiply by O(N) for each step. It's also a small change to get the multiples to remove to start at n×n instead of n.
i←¯1⋄{⍵~n×n↓⍳1+⌊N÷n←i⊃⍵⊣i+←1}⍣≡1↓1+⍳N
I think this is about as good as can be done with ~ instead of marking out bits. And I wouldn't say it's as easy as the imperative version!
>A lot of smart people only engage with APL via toy puzzles
I think part of this is because that is how most (possibly all) sources teach APL and array languages, solving puzzles and manipulating arrays. If you learn to write programs in an Algol derived language, you can write programs in most common languages without having to learn how to write programs, you just need to learn the language. Modern array languages sort of allow us to use them like the Algol derived languages, but this does not seem to work out so well and often does not work to the strengths of array languages.
I basically feel the same way. In a way it is very liberating. All of those esoteric languages that were on my ever-growing todo list are now things I can let go of. Ultimately we have to ask ourselves how we want to spend our time, and now it is much harder to justify spending countless hours studying one programming language after another. We still can, of course, but we are now more "free" to do other things instead.
It's sort of sad, but really I think it is a weight off my shoulders.
I had a little excursion into Dyalog APL recently and wound up writing an emacs mode to evaluate Dyalog APL [1]. It was a pretty nice experience using Claude to extract the small subset of features I wanted from gnu-apl-mode [2] to work with Dyalog APL.
I’d really like to properly get into APL though. My plan is to solve a bunch of problems on Kattis [3].
I'm really enjoying this way of learning a new language in the age of LLMs - starting with easy problems on an online code judge website and work with an LLM to come up with/explain simple solutions. It gives me dopamine hits, lots of reps, allows me to start coding right away, and is a nice way to slowly ramp up difficulty and get practice with different features of the language.
I am really surprised that no-one mentioned https://www.uiua.org/ yet. If you like APL/BQN/K/L, look at Uiua! You're going to love it! It's very ergonomic, and has awesome and fun facilities for audio and video rendering!
Nice to see this getting the Jupyter Notebook treatment. The original book was already one of the better introductions to APL. Interactive examples make a huge difference for a language where half the learning curve is just building muscle memory with the symbols
Given you could even use it commercially (it requires an enterprise license, but I suppose Matlab does too), moderately useful conceptually, weakly useful mechanically. APL is very limited in what offers you. I did a ML course in Matlab a while ago and I remember I could scalar loops and procedural scripts, had nice tables and object-ike structures. You'd give that all up in APL so it wouldn't help you there, but you'd see how far you can get only with creative 'array language semantics'.
It does, over time. It changes the way you think about computational problem solving. It's like the difference between designing objects in 2D on a drafting table and moving to 3D CAD. It changes your brain visualizes, explores and solves problems.
That said, learning APL isn't about learning the symbols any more than learning mathematics is not about learning the meaning of the various symbols it uses. To continue with that parallel, it also isn't about memorizing formulas. It is about using the tools to solve problems and, over time, changing the way you solve problems...now in 3D.
I learned APL in the early 80's and used it professionally for about ten years. The way I think of solving problems is fundamentally different in many ways because of this experience.
In the modern world there is no place for the commercial compiler. They should have made it free (and open source) and only IDE (maybe) paid one. Even better - push into GCC or LLVM.
I agree with you in principal, but I don't think that that's realistic at all, since that would completely destroy Dyalog's entire business model. I personally have little interest in learning a non-FOSS programming language, but Dyalog's paying customers are clearly okay with it, so I see little reason for them to change.
But why? Commercial APL implementations have existed since decades ago. They always had customers. They were always at least partly owned by employees. Dyalog was not created in a void, but continuing this tradition.
It always felt strange to me that the main implementation of something as niche and esolang-adjacent as APL is neither OSS nor casually usable commercially, but instead comes under an enterprise license.
Anyway, I had a fun time a while ago translating APL programs to NumPy. At some point you get what APL is all about, and you can move on with life without too many regrets. Turns out most of the time it's more like a puzzle to get an (often inefficient) terse implementation by torturing some linear algebra operators.
If you're after a language that's OSS, has terse notation, and rewires your brain by helping you think more clearly instead of puzzle-solving, TLA+ is the answer.
Edit: if you're curious to see at a glance what APL is all about:
APL code:
(2=+⌿0=∘.|⍨⍳N)/⍳N <- this computes primes up to N and is presented as the 'Hello world' of APL.
Equivalent NUMPY code:
```
R = np.arange(1, N + 1) # ⍳N
divides = (R[None, :] % R[:, None]) == 0 # 0=∘.|⍨⍳N
divisor_counts = divides.sum(axis=0) # +⌿
result = R[divisor_counts == 2] # (2=...)/⍳N
```
As you can see, the famous prime generator is not even the Eratostenes' sieve, but a simple N^2 divisor counting computation.
> Turns out most of the time it's more like a puzzle to get an (often inefficient) terse implementation by torturing some linear algebra operators.
solutions in APL can be very efficient if they are written in a machine sympathetic way
or in cases where the interpreter can map them onto one
for the curious:
https://aplwiki.com/wiki/Performance
https://www.youtube.com/watch?v=-6no6N3i9Tg (The Interpretive Advantage)
https://ummaycoc.github.io/wc.apl/ (Beating C with Dyalog APL: wc)
Thanks for the response. I'd interpret it as a valid technical caveat, but it feels somewhat orthogonal to what I was pointing out.
You focus on the 'often inefficient' parenthetical, yet, to me, your response highlights the puzzle nature of the thinking APL encourages. If anything, it shifts the question from 'how do I express this tersely' to a still narrower 'how do I express this tersely in a way the interpreter can also optimize'.
I think every programming language to a degree has some kind of puzzle aspect
I'm not sure APL has more or less of it compared to other languages
for example in Python, even though the language has a concept of "There should be one-- and preferably only one --obvious way" (PEP 20) it is quite multi paradigm, which I think is a strength of Python
oop, functional, imperative, …
and you get tons of libraries to choose from
e.g. numpy, pandas, polars, pytorch, keras, jax, … etc
but you still also have to figure out the algorithm and data structures you want to use (like in any language)
and you also kinda want to know (if you care about performance) how pytorch differs from numpy and how that differs from using a list with boxed values
Not saying this is not the case with APL
it definitely helps if you are familiar with the APL implementation you're using if you care about performance
I just don't think it's a disadvantage of APL over other languages
Agreed. I think I shouldn't put hard boxes around languages like 'puzzle language' vs 'abstraction/clear thinking language'.
What I was trying to point at was more specific: the way I experience APL thinking tends toward 'expression search' and 'notation compression', which feels, to me at least, somewhat at odds with clarity about the underlying problem. More often than not, I seemed to produce an APL-shaped model of the problem rather than a problem-shaped model expressed in a language.
When I first learned about APL, I was looking for new ways to think about computation. What I found was a language that rewarded deciphering APL programs and generating clever new ones. That is interesting and beautiful, but it was not quite the kind of brain-rewiring I was looking for. My original comment was targeting people in a position similar to mine and trying to set expectations about what they would learn best from APL. APL may change how you think about array expressions and how far they can go, but TLA+ is much closer to what I'd recommend if what you want is clearer thinking about programs, systems and state.
ty for the pointer to TLA+
BQN exists and needs more attention I think. It has some modern affordances as well.
https://github.com/mlochbaum/BQN
https://mlochbaum.github.io/BQN/doc/quick.html
> At some point you get what APL is all about, and you can move on with life without too many regrets.
Unfortunately, this seems to be a common experience. A lot of smart people only engage with APL via toy puzzles, like you did, and bounce off because that gives no insight about how to use the language in real life. IME, to really start getting APL you need to write and rewrite a full application 20 times.
It helps to read code from the masters, too [0, 1, 2, 3, 4]. These all approach architecture in different ways: pedagogical FP style, OOP heavy, data-oriented design, event-driven state-machine, or a mix of the above.
[0]:https://dfns.dyalog.com/
[1]:https://github.com/Co-dfns/MicroUI-APL
[2]:https://github.com/Dyalog/ewc
[3]:https://github.com/Co-dfns/Co-dfns
[4]:https://github.com/Dyalog/Jarvis/blob/master/Source/Jarvis.d...
> As you can see, the famous prime generator is not even the Eratostenes' sieve, but a simple N^2 divisor counting computation.
Well, that's because you wrote a divisor function, not a seive. Arguably, the ease of typing an outer product (i.e ∘.|⍨⍳N) can tempt us into writing quadratic algorithms unnecessarily, but this is just an experience issue, IMO.
If we want a seive, we can just write one directly:
The algorithm is O(N log log N) as expected of a naive Eratosthenes implementation. You'll need ⎕IO←0 if you want to try it out.There's also a faster seive by Roger Hui [0] in the dfns workspace as well as a family of prime number functions [1] for things more than just prime generation.
[0]:https://dfns.dyalog.com/n_sieve.htm
[1]:https://dfns.dyalog.com/n_pco.htm
That's not O(N log log N), it's more like N^2. Prime sieves are hard to implement well with immutable arrays for obvious reasons; there are some cool methods but they're definitely harder. I'm ashamed to be part of a community that won't cop to this.
The algorithm iterates over numbers ⍺ from 2 to N, removing the multiples that are greater than ⍺ and no greater than N from p. If the removal with ~ has to inspect all of p, then all the primes are there so we have asymptotically at least N/log N entries by the prime number theorem and we get N^2/log N time (when ⍺ is over N/2, no multiples are in range so this can be skipped, but that just cuts a constant factor 2 from the time). Conceivably p could be marked sorted, so the entries to remove could be found with a binary search. This is a bit harder to analyze, but I think each prime under √N will cause the list to change, and incur N/log N data movement. So you get at least (N/log N)^(3/2) cost, still quite a bit worse than linear.
Edit: changed the algorithm while I was writing... the new one is better, it keeps one list p of primes and one list ω of not-yet-marked-out numbers. However, primes are removed from ω one at a time, so that each of the N/log N primes has to be moved for each one before it, giving at least (N/log N)^2 cost (I mean, maybe an interpreter could binary search and also recognize when ~ only drops the first entry and do that by slicing? But the (N/log N)^(3/2) from above definitely holds). Mutating a bit array in place is pretty important to classical sieve performance.
Eep. You're right. Evidently, I didn't even know what a sieve was in this context and wrote a search instead. You got me to do a bit of research. Actually, this discussion is exactly where I think APL shows one of it's strengths. It feels like a human communication tool more than any other PL I've mucked about with. The hard parts here are not language issues but fundamental understanding ones.
It's a tad tricky to carefully analyze the asymptotics of my above prime generator, since the search space of Without (~) shrinks on each iteration. I think Merten's theorem gives an estimate of e^-γ/log(p_i), which we need to sum for all primes up to N. Taking prime density 1/log(n) and integrating N/(log x)^2 over our range is O(N^2/log N), I think.
> Mutating a bit array in place is pretty important to classical sieve performance.
Challenge accepted:
We just directly set roughly N/p items to 0 on each iteration—proper sieve semantics—which should give O(N log log N), unless I'm missing something.It's possible to get O(N^(3/2)/log N) in an ordinary interpreter with some changes to the code, assuming linear-time ~ with hashing. The idea is to leave the primes in ⍵ and stop when it stops changing, which will happen at the first prime over √N. To get the complexity multiply by O(N) for each step. It's also a small change to get the multiples to remove to start at n×n instead of n.
I think this is about as good as can be done with ~ instead of marking out bits. And I wouldn't say it's as easy as the imperative version!>A lot of smart people only engage with APL via toy puzzles
I think part of this is because that is how most (possibly all) sources teach APL and array languages, solving puzzles and manipulating arrays. If you learn to write programs in an Algol derived language, you can write programs in most common languages without having to learn how to write programs, you just need to learn the language. Modern array languages sort of allow us to use them like the Algol derived languages, but this does not seem to work out so well and often does not work to the strengths of array languages.
It’s not truly fair to call it an esolang given that it was used by mainframe customers for decades. It’s more like a less popular product than COBOL…
> Turns out most of the time it's more like a puzzle to get an (often inefficient) terse implementation by torturing some linear algebra operators.
In vector function space, no one can hear your eigen-scream.
related: blog post on fast primes in BQN
https://panadestein.github.io/blog/posts/ps.html
> If you're after a language that's OSS, has terse notation, and rewires your brain by helping you think more clearly
I found MATLAB/Octave was good
Matrix conjugate transpose:
but instead comes under an enterprise license.
The reason for this is because APL is quite popular in fintech, and of course that industry has no qualms about things not being free.
https://lamport.azurewebsites.net/tla/tla.html ?
Yes! I put together some explanation and TLA+ related resources in this comment, the website is one of them: https://news.ycombinator.com/item?id=48075169
Is it evaluated lazily? How about APL?
[flagged]
> At some point you get what APL is all about, and you can move on with life without too many regrets.
Honestly this is how computers/software/programming feel in general these days and it’s ruined it all for me.
I basically feel the same way. In a way it is very liberating. All of those esoteric languages that were on my ever-growing todo list are now things I can let go of. Ultimately we have to ask ourselves how we want to spend our time, and now it is much harder to justify spending countless hours studying one programming language after another. We still can, of course, but we are now more "free" to do other things instead.
It's sort of sad, but really I think it is a weight off my shoulders.
A more concise intro to APL for the modern era: https://xpqz.github.io/learnapl
(author)
I had a little excursion into Dyalog APL recently and wound up writing an emacs mode to evaluate Dyalog APL [1]. It was a pretty nice experience using Claude to extract the small subset of features I wanted from gnu-apl-mode [2] to work with Dyalog APL.
I’d really like to properly get into APL though. My plan is to solve a bunch of problems on Kattis [3].
I'm really enjoying this way of learning a new language in the age of LLMs - starting with easy problems on an online code judge website and work with an LLM to come up with/explain simple solutions. It gives me dopamine hits, lots of reps, allows me to start coding right away, and is a nice way to slowly ramp up difficulty and get practice with different features of the language.
[1] https://github.com/ebanner/dyalog-mode
[2] https://github.com/lokedhs/gnu-apl-mode
[3] https://open.kattis.com
I am really surprised that no-one mentioned https://www.uiua.org/ yet. If you like APL/BQN/K/L, look at Uiua! You're going to love it! It's very ergonomic, and has awesome and fun facilities for audio and video rendering!
Nice to see this getting the Jupyter Notebook treatment. The original book was already one of the better introductions to APL. Interactive examples make a huge difference for a language where half the learning curve is just building muscle memory with the symbols
APL workspaces substantially predate Jupyter notebooks!
For those like me who prefer a PDF:
https://www.dyalog.com/uploads/documents/MasteringDyalogAPL....
How useful would learning APL be for writing less strictly array-based languages like Matlab?
Given you could even use it commercially (it requires an enterprise license, but I suppose Matlab does too), moderately useful conceptually, weakly useful mechanically. APL is very limited in what offers you. I did a ML course in Matlab a while ago and I remember I could scalar loops and procedural scripts, had nice tables and object-ike structures. You'd give that all up in APL so it wouldn't help you there, but you'd see how far you can get only with creative 'array language semantics'.
Dyalog APL, along with other modern array languages that are related to it can all do imperative programming with loops etc.
There are certainly valid arguments that you hive certain things up when moving to an array language, but loops are not one of those.
That said, you won't use loops as much, but that's not because loops are not available.
I have no use for APL, yet this looks like a great bookmark for rainy days.
I really wish learning this had a positive RoI
It does, over time. It changes the way you think about computational problem solving. It's like the difference between designing objects in 2D on a drafting table and moving to 3D CAD. It changes your brain visualizes, explores and solves problems.
That said, learning APL isn't about learning the symbols any more than learning mathematics is not about learning the meaning of the various symbols it uses. To continue with that parallel, it also isn't about memorizing formulas. It is about using the tools to solve problems and, over time, changing the way you solve problems...now in 3D.
I learned APL in the early 80's and used it professionally for about ten years. The way I think of solving problems is fundamentally different in many ways because of this experience.
It has a huge RoI, even if you never use it in anger. It’s a bit like Lisp in that regard — it shapes your thinking.
[flagged]
In the modern world there is no place for the commercial compiler. They should have made it free (and open source) and only IDE (maybe) paid one. Even better - push into GCC or LLVM.
I agree with you in principal, but I don't think that that's realistic at all, since that would completely destroy Dyalog's entire business model. I personally have little interest in learning a non-FOSS programming language, but Dyalog's paying customers are clearly okay with it, so I see little reason for them to change.
But why? Commercial APL implementations have existed since decades ago. They always had customers. They were always at least partly owned by employees. Dyalog was not created in a void, but continuing this tradition.
fwiw Dyalog APL is free for non-commercial use:
https://www.dyalog.com/prices-and-licences.htm
typical implementations of apl (including dyalog) are interpreted, not compiled ahead of time.