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.
> 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.
chillpenguin 56 minutes ago [-]
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.
adamgordonbell 2 hours ago [-]
BQN exists and needs more attention I think. It has some modern affordances as well.
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.
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
I have no use for APL, yet this looks like a great bookmark for rainy days.
Pay08 3 hours ago [-]
How useful would learning APL be for writing less strictly array-based languages like Matlab?
gobdovan 2 hours ago [-]
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'.
lokedhs 2 hours ago [-]
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.
UltraSane 4 hours ago [-]
I really wish learning this had a positive RoI
skruger 2 hours ago [-]
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.
robomartin 3 hours ago [-]
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.
Rendered at 17:19:25 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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)
Honestly this is how computers/software/programming feel in general these days and it’s ruined it all for me.
It's sort of sad, but really I think it is a weight off my shoulders.
https://github.com/mlochbaum/BQN
https://mlochbaum.github.io/BQN/doc/quick.html
(author)
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
https://www.dyalog.com/uploads/documents/MasteringDyalogAPL....
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.
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.