Live data from Hacker News

Mastering Dyalog APL

mastering.dyalog.com

11–20 of 43 posts

Re: Mastering Dyalog APL

#11
post #9

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…

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

Re: Mastering Dyalog APL

#12
post #7

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…

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.

Re: Mastering Dyalog APL

#13
post #9

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…

https://lamport.azurewebsites.net/tla/tla.html ?

Re: Mastering Dyalog APL

#16
post #13
post #9

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…

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

Re: Mastering Dyalog APL

#17
post #9

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…

> 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.

Re: Mastering Dyalog APL

#18
post #9

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…

> 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.

Re: Mastering Dyalog APL

#19
post #9

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…

> 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)

Re: Mastering Dyalog APL

#20
post #19
post #9

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…

> 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) h…

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'.

Post reply on HN