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.
Off topic, but if you really want to use an alternative to qwerty, try colemak — it keeps many of the most common shortcuts the same (ie QAZXCV all remain in the place) which makes it a little easier to transition.
(It also has a few other benefits over Dvorak, optimising for a few more factors than Dvorak does)
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.
Considering the complete absence of array languages in a field dominated by operations on tensors, I think it is fair to say that the terse array programming languages like APL aren't just niche languages. They're niche languages even in the category of niche languages.
In theory you should be able to define entire neural networks with the help of a handful lines of APL. You wouldn't even bother with complex frameworks offering you pre-built architectures. You'd just copy paste the 10 lines of fully self contained APL code that describes the network from the documentation, because even the idea of downloading a library is overkill.
RIP, razetime.
[0] https://codegolf.meta.stackexchange.com/questions/26416/in-m...
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
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/
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.
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.
(It also has a few other benefits over Dvorak, optimising for a few more factors than Dvorak does)
In theory you should be able to define entire neural networks with the help of a handful lines of APL. You wouldn't even bother with complex frameworks offering you pre-built architectures. You'd just copy paste the 10 lines of fully self contained APL code that describes the network from the documentation, because even the idea of downloading a library is overkill.