_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Mastering Dyalog APL
xvilka wrote 1 day ago:
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.
5- wrote 1 day ago:
typical implementations of apl (including dyalog) are interpreted,
not compiled ahead of time.
tosh wrote 1 day ago:
fwiw Dyalog APL is free for non-commercial use:
(HTM) [1]: https://www.dyalog.com/prices-and-licences.htm
radiator wrote 1 day ago:
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.
gucci-on-fleek wrote 1 day ago:
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.
skruger wrote 1 day ago:
A more concise intro to APL for the modern era: [1] (author)
(HTM) [1]: https://xpqz.github.io/learnapl
gobdovan wrote 1 day ago:
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.
zerr wrote 18 hours 12 min ago:
Is it evaluated lazily? How about APL?
fnord77 wrote 1 day ago:
> 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:
H = A';
xelxebar wrote 1 day ago:
> 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]: [1]: [2]: [3]: [4] [4]: [5] > 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.
[0]: [1] n_sieve.htm
[1] n_pco.htm
(HTM) [1]: https://dfns.dyalog.com/
(HTM) [2]: https://github.com/Co-dfns/MicroUI-APL
(HTM) [3]: https://github.com/Dyalog/ewc
(HTM) [4]: https://github.com/Co-dfns/Co-dfns
(HTM) [5]: https://github.com/Dyalog/Jarvis/blob/master/Source/Jarvis.d...
(HTM) [6]: https://dfns.dyalog.com/n_sieve.htm
(HTM) [7]: https://dfns.dyalog.com/n_pco.htm
mlochbaum wrote 1 day ago:
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.
mlochbaum wrote 1 day ago:
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!
ofalkaed wrote 1 day ago:
>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.
userbinator wrote 1 day ago:
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.
wwweston wrote 1 day ago:
> 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.
shrubble wrote 1 day ago:
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â¦
tosh wrote 1 day ago:
related: blog post on fast primes in BQN
(HTM) [1]: https://panadestein.github.io/blog/posts/ps.html
tosh wrote 1 day ago:
> 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: [1] [2] (The Interpretive Advantage) [3] (Beating C
with Dyalog APL: wc)
(HTM) [1]: https://aplwiki.com/wiki/Performance
(HTM) [2]: https://www.youtube.com/watch?v=-6no6N3i9Tg
(HTM) [3]: https://ummaycoc.github.io/wc.apl/
gobdovan wrote 1 day ago:
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'.
tosh wrote 1 day ago:
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
gobdovan wrote 1 day ago:
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.
tosh wrote 1 day ago:
ty for the pointer to TLA+
blowscum wrote 1 day ago:
> 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 wrote 1 day 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.
floxy wrote 1 day ago:
[1] ?
(HTM) [1]: https://lamport.azurewebsites.net/tla/tla.html
gobdovan wrote 1 day ago:
Yes! I put together some explanation and TLA+ related resources in
this comment, the website is one of them:
(HTM) [1]: https://news.ycombinator.com/item?id=48075169
adamgordonbell wrote 1 day ago:
BQN exists and needs more attention I think. It has some modern
affordances as well. [1]
(HTM) [1]: https://github.com/mlochbaum/BQN
(HTM) [2]: https://mlochbaum.github.io/BQN/doc/quick.html
meken wrote 1 day ago:
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] [2]
(HTM) [1]: https://github.com/ebanner/dyalog-mode
(HTM) [2]: https://github.com/lokedhs/gnu-apl-mode
(HTM) [3]: https://open.kattis.com
Pay08 wrote 1 day ago:
How useful would learning APL be for writing less strictly array-based
languages like Matlab?
gobdovan wrote 1 day 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 wrote 1 day 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.
twoodfin wrote 1 day ago:
For those like me who prefer a PDF:
(HTM) [1]: https://www.dyalog.com/uploads/documents/MasteringDyalogAPL.pd...
UltraSane wrote 1 day ago:
I really wish learning this had a positive RoI
skruger wrote 1 day 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 wrote 1 day 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.
pjmlp wrote 1 day ago:
I have no use for APL, yet this looks like a great bookmark for rainy
days.
raghavchamadiya wrote 1 day ago:
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
MayCXC wrote 7 hours 3 min ago:
APL workspaces substantially predate Jupyter notebooks!
(DIR) <- back to front page