For those unaware: Ragu "razetime" Ranganathan, the author of this repository, died in an accident last year at just 22 years old. He already had a tremendous positive impact on the array language community in his short time with us on earth, see also this tribute[0] on the codegolf stackexchange site. I remember him from various proglang discord servers and other language forums, and had no idea he was that young as he was extremely knowledgeable, and wise beyond his years. It still feels unreal that he's gone.
The three things I have repeatedly failed to learn, they just don't seem to stick for me: Dvorak, Specter[1] (the Clojure library), and APL. So I appreciate these tips whenever I find them.
My issue with APL is I was never able to turn the corner to "generic problem solving" in APL (or other array langs). It feels like learning written Chinese, like 50,000 individual techniques but if you know them you can do incredible things quickly. For the problems I know how to solve, I can solve them quickly. And you CAN do amazing things with inner products in APL.
On the other hand, studying APL, even if you don't master it, is not without benefits. LLM transformer architecture and GraphBLAS algorithms are junior APL level implementation problems (at least conceptually, operationalizing them is a different story).
Adam Brudzewski has one of the most criminally underrated YouTube channels[2]. It would be great to solve problems that elegantly in any language, and Adam has always been very friendly in answering questions if you ever get a chance to speak with him. I just seem to be a lost cause lol.
Have you tried Uiua? Because I was in your position once, trying to grok APL, K, J, BQN but failing repeatedly. But then it clicked when I saw Uiua.
Part of that is because unlike other APL-likes it uses a stack (sort of) and I can't explain exactly how but it made it much easier for me to picture how the data flows from one operation to the next (I have to admit I like concatenative languages a lot so I'm obviously biased here too).
On top of that none of the glyphs are overloaded with monadic and dyadic versions, they're one or the other, which reduces ambiguity a lot when trying to read/write code.
There's lots of other little ergonomic tweaks to it that make it really neat, but those were the big ones for me.
Also worth noting is that it has lots of multimedia support - you can generate pictures, gif animations, sounds. So it's easy to "play" with for fun!
I take some issue with the implied suggestion that Brainfuck isn't serious, but that's probably my arts degree talking.
Anyway, under the assumption that I'm correctly guessing what you have in mind when using the words "serious language", Uiua certainly qualifies. The author is very passionate about exploring and discovering "the good parts" of the design space of the array language paradigm, and has put a ton of work into making it accessible and practically useful within the constraints of being an interpreted language that autoformats its source code to at-first exotic looking maths symbols.
I wanted to learn APL and made some progress by writing semi-useful tools for a machine learning preprocessing pipeline using GNU APL (APL2). It was great fun and not too difficult; I just had to get used to the idea that the core data type is an array. Using the terse syntax made it feel very similar to writing mathematical notation in a student's maths class.
However, I felt that writing anything not closely related to solving mathematical matrix problems made no sense to me. Unfortunately, APL is too niche; I don't know anyone in my industry with whom I could share the tools. Nevertheless, it was a valuable learning experience.
This looks like language implementation specific tips and tricks for array oriented paradigm programming languages rather than principles techniques and methods for efficient array computations.
Array-oriented languages like APL offer some unique approaches to writing efficient code. Thanks for compiling resources and examples—it’s helpful for developers interested in learning these paradigms.
For those unaware: Ragu "razetime" Ranganathan, the author of this repository, died in an accident last year at just 22 years old. He already had a tremendous positive impact on the array language community in his short time with us on earth, see also this tribute[0] on the codegolf stackexchange site. I remember him from various proglang discord servers and other language forums, and had no idea he was that young as he was extremely knowledgeable, and wise beyond his years. It still feels unreal that he's gone.
RIP, razetime.
[0] https://codegolf.meta.stackexchange.com/questions/26416/in-m...
The three things I have repeatedly failed to learn, they just don't seem to stick for me: Dvorak, Specter[1] (the Clojure library), and APL. So I appreciate these tips whenever I find them.
My issue with APL is I was never able to turn the corner to "generic problem solving" in APL (or other array langs). It feels like learning written Chinese, like 50,000 individual techniques but if you know them you can do incredible things quickly. For the problems I know how to solve, I can solve them quickly. And you CAN do amazing things with inner products in APL.
On the other hand, studying APL, even if you don't master it, is not without benefits. LLM transformer architecture and GraphBLAS algorithms are junior APL level implementation problems (at least conceptually, operationalizing them is a different story).
Adam Brudzewski has one of the most criminally underrated YouTube channels[2]. It would be great to solve problems that elegantly in any language, and Adam has always been very friendly in answering questions if you ever get a chance to speak with him. I just seem to be a lost cause lol.
[1]: https://github.com/redplanetlabs/specter
[2]: https://www.youtube.com/@abrudz
Have you tried Uiua? Because I was in your position once, trying to grok APL, K, J, BQN but failing repeatedly. But then it clicked when I saw Uiua.
Part of that is because unlike other APL-likes it uses a stack (sort of) and I can't explain exactly how but it made it much easier for me to picture how the data flows from one operation to the next (I have to admit I like concatenative languages a lot so I'm obviously biased here too).
On top of that none of the glyphs are overloaded with monadic and dyadic versions, they're one or the other, which reduces ambiguity a lot when trying to read/write code.
There's lots of other little ergonomic tweaks to it that make it really neat, but those were the big ones for me.
Also worth noting is that it has lots of multimedia support - you can generate pictures, gif animations, sounds. So it's easy to "play" with for fun!
[0] https://www.uiua.org/
I assumed Uiua was "the same" but this is the first I'm hearing the experience might be different. I will check it out, thanks!
Wait, Uiua is a serious language? At first glance it looks like it's trying to be brainfuck.
I take some issue with the implied suggestion that Brainfuck isn't serious, but that's probably my arts degree talking.
Anyway, under the assumption that I'm correctly guessing what you have in mind when using the words "serious language", Uiua certainly qualifies. The author is very passionate about exploring and discovering "the good parts" of the design space of the array language paradigm, and has put a ton of work into making it accessible and practically useful within the constraints of being an interpreted language that autoformats its source code to at-first exotic looking maths symbols.
I wanted to learn APL and made some progress by writing semi-useful tools for a machine learning preprocessing pipeline using GNU APL (APL2). It was great fun and not too difficult; I just had to get used to the idea that the core data type is an array. Using the terse syntax made it feel very similar to writing mathematical notation in a student's maths class.
However, I felt that writing anything not closely related to solving mathematical matrix problems made no sense to me. Unfortunately, APL is too niche; I don't know anyone in my industry with whom I could share the tools. Nevertheless, it was a valuable learning experience.
There are only ~80 glyphs in APL, and only ~50 are really commonly used.
If you like array languages: https://www.reddit.com/r/apljk/
This looks like language implementation specific tips and tricks for array oriented paradigm programming languages rather than principles techniques and methods for efficient array computations.
Array-oriented languages like APL offer some unique approaches to writing efficient code. Thanks for compiling resources and examples—it’s helpful for developers interested in learning these paradigms.
Please stop writing AI slop.