Aaron Hsu discusses design patterns and anti-patterns in APL and why the language is productive despite its write-only reputation. He argues that idioms matter more than libraries in array languages.
Why Hacker News points people here: HN recommends it as a terrific talk on APL readability and on the idea of idioms over libraries.
All of the languages you mentioned are watered-down and inferior versions of the programming models invented by APL and J. By that I don't mean that APL/J are unilaterally better -- there are plenty of practical reasons to choose R/Matlab/numpy -- but they are unquestionably more beautiful and visionary. They hang together at a deep level in a way those languages do not. They are also much harder to learn, and much more fun. On the readability of APL (terrific video): this video Alan Perlis on its beauty: link
Strongly recommendsmyco_logicAug 2022
“his fantastic talk on anti-patterns in the Iversonian languages”
Fantastic talk on idioms over libraries in array languages
Full comment
> It feels like there's an unexplored dimension of abstraction here. Something where generics, interfaces and higher order functions are too static and low level primitives. Something where it's really difficult to pinpoint what exactly is the repeated pattern here and how to exploit it. Instead of generic framework that can do everything, I'd like an efficient way do something specific. This bit reminds me a lot of a concept Aaron Hsu mentions in his fantastic talk on anti-patterns in the Iversonian languages[0], a paradigm he terms "Idioms over Libraries". The idea being that because of the expressive power of APL's primitives programmers often opt for utilizing easily recalled snippets of symbols over the importing of library code to implement common functionality. This facet of array-lang culture can be seen with sites like APL Cart[1], which serve as indexes of these frequently used snippets. I think a lot of people miss that this is one of the major advantages induced by the terseness of these languages (it's not just about code-golfing for the implicit joy of laconicism). By allowing for the direct expression of algorithms in the same context they are being used, APL and its kin enable one to tweak and optimize these idioms on a case-by-case basis: precisely the kind of specificity the author of this article is asking for. [0]: this video [1]: link
RecommendskadblasJun 2019
“The main takeaway from this video for me was the principle of”
Introduces the principle of idioms over libraries
Full comment
Qualification: I was introduced to FP a number of years ago and have finally reached a point where I feel that I have a deep understanding of FP in general. In my mind, Haskell is the "best" language out there ("best" in that it provides the best overall gain when all tradeoffs are considered). I'm no longer confident that Haskell is the "best" language anymore. I was recently introduced to a language that might be even better than Haskell: Dyalog APL. ( link ). Try it out yourself ( link ) To explain why, I recommend watching Aaron Hsu's videos on Dyalog APL: - Does APL need a Type System? ( link ) - This is actually a very interesting question that is more nuanced than upon first glance. - Design Patterns and Anti-Patterns in APL ( this video ) - The main takeaway from this video for me was the principle of "Idioms over libraries." - Higher Performance Tree-Wrangling, the APL way ( link ) - Or how to model Trees without using pointers by using "Inverted Tables." (An inverted table is a table where the columns are the rows and the rows are the columns)
RecommendsxelxebarDec 2019
“Aaron Hsu has a really interesting talk”
Compares APL with other languages via human-computer interfaces
Full comment
Always excited to see APL/J content on the top page. Happily, this coincides with a brand new release of the J interpreter, namely J901. It's so new that the homepage[0] still claims 901 is in beta. The install page[1], however, does have up to date information. If you would like to taste a bit of the difference before deciding to jump in, Aaron Hsu has a really interesting talk[2] that compares APL and "other" languages via the lens of Human-Computer Interfaces. I am just beginning my journey into J, but so far it has been extremely rewarding. Head on over to #jsoftware on Freenode. The channel is super small, but has some really friendly and helpful people on it! [0]: link [1]: link [2]: this video
Cites itognyankulevMar 2018
Second recording of the same APL patterns talk
Full comment
Two talks with these slides: 1. link (Dyalog17: Patterns and Anti-patterns in APL: Escaping the Beginner's Plateau) 2. this video (Design Patterns vs Anti pattern in APL by Aaron W Hsu at FnConf17)
Cites ita-salehJun 2019
“was amused that there is this world where programming is just symbols :D”
Amusing glimpse of symbol-only programming
Full comment
Maybe look at a different programming paradigm then? :) I remember trying to learn APL and then watching this video and was amused that there is this world where programming is just symbols :D So maybe look at i.e. something apl-like, or maybe ml or haskell or erlang, where so many things you can do with functions and composing them, or even Prolog, where everything could be thought of as a set of rules/constraints to be solved (I think? haven't programmed in Prolog since uni :) )
Cites itarcfideNov 2019
“there is some evidence to suggest that APL is actually arranged in a manner more natural for the human faculty than most computing languages”
Author's talk on APL being natural for humans
Full comment
It's really no more difficult than learning recursion, pointers, memory allocation, type theory, functional programming, iterative programming, OOP, or any other of the myriad techniques that we use for computing. As I mention in my talk on APL design patterns, it's largely a matter of what we have been trained to understand, and there is some evidence to suggest that APL is actually arranged in a manner more natural for the human faculty than most computing languages: this video
Cites itinvalidOrTakenMar 2020
Tangential mention in a long anecdote
Full comment
A story, since in retrospect I think it's worth telling. Some years ago I was at the SF Clojure meetup. Arthur Whitney's daughter worked at the sponsoring company, and he agreed to come tell us about K. In retrospect, I don't think we gave him the welcome he deserved. No one was rude or anything, but it seemed there was a disconnect: Arthur was keen to show off how fast K (and Kdb) was, over zillions and zillions of rows. But the thing that the Clojurists were all searching for (that got them into Clojure in the first place) was expressivity . Is Clojure fast? I don't know, generally the problems I face come down to avoiding balls of mud rather than performance bottlenecks. And I think that was true of most there. So Arthur got something of an underwhelming reception. I remember someone asking "Does K have the ability to self-modify, a la Lisp macros?" When Arthur said no, you could see most people in the room just sort of mentally shrug and move on. And this was too bad. Because recently I've been playing around with J (another APL descendant) and been very impressed by some expressivity/readability benefits. Some small things that have very big effects on the codebase you actually end up with. The first thing is the avoidance of abstraction. To use a Twitterism: Broke: Just write your code and don't divide it into functions, creating one long main method Woke: Divide your code up, naming parts that get reused Bespoke: If your code is made up of really really short things, i
Cites itinvalidOrTakenSep 2021
Repost of an earlier comment on expressivity
Full comment
Comment from a year ago( link ): >A story, since in retrospect I think it's worth telling. Some years ago I was at the SF Clojure meetup. Arthur Whitney's daughter worked at the sponsoring company, and he agreed to come tell us about K. >In retrospect, I don't think we gave him the welcome he deserved. No one was rude or anything, but it seemed there was a disconnect: Arthur was keen to show off how fast K (and Kdb) was, over zillions and zillions of rows. >But the thing that the Clojurists were all searching for (that got them into Clojure in the first place) was expressivity. Is Clojure fast? I don't know, generally the problems I face come down to avoiding balls of mud rather than performance bottlenecks. And I think that was true of most there. >So Arthur got something of an underwhelming reception. I remember someone asking "Does K have the ability to self-modify, a la Lisp macros?" When Arthur said no, you could see most people in the room just sort of mentally shrug and move on. >And this was too bad. Because recently I've been playing around with J (another APL descendant) and been very impressed by some expressivity/readability benefits. Some small things that have very big effects on the codebase you actually end up with. >The first thing is the avoidance of abstraction. To use a Twitterism: >Broke: Just write your code and don't divide it into functions, creating one long main method >Woke: Divide your code up, naming parts that get reused >Bespoke: If your code
