Man, I feel like APL has unlocked some latent part of my brain.
I'm a few years into seriously using APL and now work in it professionally doing greenfield development work.
Starting out, solving puzzles and stuff was fun, but trying to write real programs, I hit a huge wall. It took concerted effort, but learning to think with data-first design patterns and laser focusing on human needs broke through that barrier for me.
Writing APL that feels good and is maintainable ends up violating all kinds of cached wisdom amongst developers, so it's really hard to communicate just how brutally simple things can be and how freeing that is.
i worked in APL2 fulltime years ago, big asset backed bond models, big as in some of the largest workspaces the IBM support people had ever seen. Never occurred to me to pick it up again, but i have been looking for the Polivka/Pakin book i learned out of (the edition prior to their APL2 edition).
I came to APL slowly, originally motivated by some combination of fascination with the syntax and desire to break into the financial sector.
However, what got me to invest in earnest study was hitting today beginner's wall and realizing that I had no idea what Iverson was on about with his design principles.
APL is really different these days, as far as I hear. Dyalog APL is the only vendor actively working on the language these days, and the old hats tell me that things like dfns, trains, and various operators make modern APL quite different from APL even just 15 years ago.
My YAML loader[0] is where I first broke through the wall. It's still languishing in a relatively proof-of-concept state but does exhibit the basic design principles.
There's also a Metamath verifier that does parallel proof verification on the GPU. It's unpublished right now because the whole thing is just a handful of handwritten code in my notebook at the moment. Hoping to get this out this month, actually.
A DOOM port is bouncing around in my notes as well as a way to explore asynchronous APL.
I'm also helping Aaron Hsu in his APL compiler[1] for stuff adjacent to my professional work, which I can't comment on much, unfortunately.
And on sci-hub, it is really unfortunate that IEEE hasn't followed the ACM and removed their paywall for ancient articles. Esp since ostensibly, IEEE isn't a forprofit entity, these old articles have zero monetary value.
you can't imagine something being relevant because the AI doesn't know about it? Seems like more a fault of the AI if you ask me. There is a huge amount of information that hasn't been—or cannot—be captured in the data LLMs are trained on.
I'm a few years into seriously using APL and now work in it professionally doing greenfield development work.
Starting out, solving puzzles and stuff was fun, but trying to write real programs, I hit a huge wall. It took concerted effort, but learning to think with data-first design patterns and laser focusing on human needs broke through that barrier for me.
Writing APL that feels good and is maintainable ends up violating all kinds of cached wisdom amongst developers, so it's really hard to communicate just how brutally simple things can be and how freeing that is.
i worked in APL2 fulltime years ago, big asset backed bond models, big as in some of the largest workspaces the IBM support people had ever seen. Never occurred to me to pick it up again, but i have been looking for the Polivka/Pakin book i learned out of (the edition prior to their APL2 edition).
However, what got me to invest in earnest study was hitting today beginner's wall and realizing that I had no idea what Iverson was on about with his design principles.
APL is really different these days, as far as I hear. Dyalog APL is the only vendor actively working on the language these days, and the old hats tell me that things like dfns, trains, and various operators make modern APL quite different from APL even just 15 years ago.
There's also a Metamath verifier that does parallel proof verification on the GPU. It's unpublished right now because the whole thing is just a handful of handwritten code in my notebook at the moment. Hoping to get this out this month, actually.
A DOOM port is bouncing around in my notes as well as a way to explore asynchronous APL.
I'm also helping Aaron Hsu in his APL compiler[1] for stuff adjacent to my professional work, which I can't comment on much, unfortunately.
Et hoc genus omne
[0]:https://github.com/xelxebar/dayaml
[1]:https://github.com/Co-dfns/Co-dfns
You might find Stefan Kruger's book useful: https://xpqz.github.io/learnapl/intro.html or his write up of the APL Cultivations (https://xpqz.github.io/cultivations/Intro.html)
Not sure where best to start with J, although finding it interesting reading through the Dictionary (https://www.jsoftware.com/help/dictionary/contents.htm) and seeing how it compares to APL
And on sci-hub, it is really unfortunate that IEEE hasn't followed the ACM and removed their paywall for ancient articles. Esp since ostensibly, IEEE isn't a forprofit entity, these old articles have zero monetary value.