HackerTube.dev

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

ConfEngine · 7.7K views · 2017-11-29 · 54:10

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

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.

On Hacker News

HN recommends it as a terrific talk on APL readability and on the idea of idioms over libraries.

Recommended by 4 HN people across 4 months · HN mentions 2018–2022

Topics

Search by tags

What people said

myco_logic · 2022-08 · Strong recommendation

> 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]: [VIDEO] [1]: [LINK]

Read the original HN comment ↗
jonahx · 2019-04 · Strong recommendation

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): [VIDEO] Alan Perlis on its beauty: [LINK]

Read the original HN comment ↗
xelxebar · 2019-12 · Recommendation

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]: [VIDEO]

Read the original HN comment ↗

Sources

Video by ConfEngine, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources