HackerTube.dev

Does APL Need a Type System? by Aaron W Hsu at #FnConf18

ConfEngine · 6.4K views · 2019-02-25 · 54:31

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's FnConf18 talk asks whether APL needs a static type system. He argues that APL's expressiveness and rapid iteration already deliver the benefits usually credited to types.

On Hacker News

HN points to it as the main argument from the array-language camp that types are unnecessary there, and as a nuanced take on typed versus untyped programming.

Recommended by 3 HN people across 3 months · HN mentions 2019–2025

Topics

Search by tags

What people said

kadblas · 2019-06 · Strong recommendation

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? ( [VIDEO] ) - This is actually a very interesting question that is more nuanced than upon first glance. - Design Patterns and Anti-Patterns in APL ( [LINK] ) - 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)

Read the original HN comment ↗
eggy · 2020-04 · Recommendation

The right tool for the job. If you are building a huge website with input forms, videos, data collection, ML algorithms, yes then you wouldn't do the whole thing in APL or J even if you could. Python is big in ML because packages for working with data in array language ways were developed. Pandas by Wes McKinney is one example, and he studied J or q, and even tweeted: IMHO J is the best APL for data analysis because of its broad suite hash table-based functions. I like APL and J as a scratchpad where arrays are the basic unit and not scalars. J is functional and it turned me on to that world before I touched Haskell or F#. Aaron Hsu has a lot of great videos that speak to a lot of the usability and scaling out you mention: [LINK] I particularly like this one: [VIDEO] I am able to grasp concepts or own them after coding them in APL or J even if the code isn't as fast such as how well APL applies to Convolutional Neural Networks [1,2]. I really understood the mechanics of CNNs better after working through this paper a lot more than books I had read on ANNs in general since the late 80s/early 90s. By contrast, I have coded ANNs in C and Python, and I get lost in the PL, not the concept, if that makes sense. Anyway, I am a polyglot and find people criticize J/APL/k etc. from a brief look without really trying to learn the language. I learned assembler and basic back in 1978 to 1982, and I felt the same way when I first looked at opcodes. [1] [LINK] [2] [LINK]

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

Just starting to learn J, myself, and this brings to mind Aaron Hsu's "Does APL Need A Type System?" talk: [VIDEO] which argues that APL already provides the development ergonomics that are typically acribed to type systems. I.e. why type check your tacit function when it's implementation is about the same length as its type annotation? Anyway, as someone trained in Category Theory and a huge fan of type systems, I found Hsu's argument surprisingly pursuasive. I would love to hear any counterpoint arguments and the motivations behind attempts at giving J a type system.

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