Design Patterns vs Anti pattern in APL by Aaron W Hsu at FnConf17

What Hacker News said

Strong rec jonahx · 2019-04 · on “J Language – New Website”

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]

Strong rec myco_logic · 2022-08 · on “Programming breakthroughs we need”

> 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

Recommends kadblas · 2019-06 · on “Why I think Haskell is the best general purpose language as of June 22 2019”

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 gla

Recommends xelxebar · 2019-12 · on “APL and J (2015)”

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

Cites ognyankulev · 2018-03 · on “APL Style: Patterns/Anti-patterns”

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 a-saleh · 2019-06 · on “Non-English-based programming languages”

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 arcfide · 2019-11 · on “Getting Started with APL (2017)”

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 invalidOrTaken · 2020-03 · on “K Language (2011)”

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