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.
Mastering Dyalog APL
21–30 of 43 posts
Re: Mastering Dyalog APL
#22In 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.
Re: Mastering Dyalog APL
#23In 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.
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.
Re: Mastering Dyalog APL
#24Earlier quoted context omitted.
> 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…
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
Re: Mastering Dyalog APL
#25In 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.
fwiw Dyalog APL is free for non-commercial use:
Re: Mastering Dyalog APL
#26It 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…
related: blog post on fast primes in BQN
Re: Mastering Dyalog APL
#27Earlier quoted context omitted.
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…
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 f…
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.
Re: Mastering Dyalog APL
#28It 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…
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…
Re: Mastering Dyalog APL
#29Earlier quoted context omitted.
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 f…
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 o…
ty for the pointer to TLA+
Re: Mastering Dyalog APL
#30It 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.
In vector function space, no one can hear your eigen-scream.