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)
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'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
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.
So, 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.
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.
(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
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.