Co-dfns Live Stream: Compiler Design and Architecture

What Hacker News said

Strong rec Nadya · 2018-02 · on “Common combinators in JavaScript”

What use is Chinese for someone who doesn't read Chinese? The S combinator written like that is perfectly legible and fine for someone who is already familiar with the S Combinator. I don't see the problem there and I don't already grok the S Combinator. I do appreciate writing code under the assumption people working on the code would have some level of prerequisite knowledge. I'm sure you'd get a kick out of Co-dfns [0]. But once you learn to "speak" APL programming it makes a lot more sense. I'd highly recommend, if you have the time, to listen to the author explaining the code for the compiler [1]. [0] [LINK] [1] [this video] / HN discussion: [LINK]

Strong rec Nadya · 2021-07 · on “Jelly: a recreational programming language inspired by J”

One of the most memorable and interesting things I've ever seen on HN was an AMA from the creator of the Co-dfns parallel APL compiler. Here is co-dfns [0] and the AMA by the creator [1]. The video may give you some insight and at the very least may be extremely interesting to hear the APL code explained (jump to around 13:30 for the beginning of the explanation behind the structure + what the compiler is doing). He explains it very well - it's quite easy to follow along. [0] [LINK] [1] [this video]

Strong rec refset · 2024-01 · on “Thinking in an array language”

Nothing has ever convinced me about the potential for array languages in practice quite like watching Aaron Hsu describe how he develops his parallel APL compiler [0] using two Notepad.exe windows side-by-side: [this video] He has also written many comments (arcfide on HN) about this stuff before, e.g. discussing "semantic density" [1] > The compiler is designed so that I can see as much as possible with as little indirection as possible, so that when I see a piece of code I not only know how it works in complete detail, but how it connects to the world around it, and every single dependency related to it in basically one single half screen full of code (usually much less than that) without any j

Strong rec Nadya · 2024-06 · on “APL Demonstration (1975) [video]”

I thought the same about APL until arcfide made a video about codfns a few years back. Was eye opening. [this video]

Recommends a-saleh · 2018-05 · on “APL deserves its renaissance too”

I remember being floored by APL few months ago when I learned about co-dnfs and watched the stream by Aaron Hsu [1] with quotes like "This code is perfectly readable, it just isn't in English". Thing is, when I was thinking about trying it, I never figured out a good toy project. Like, when I wanted to try anything else, most of the time I would know I would be able to cobble together a web-service. Haskell, Erlang, even Prolog. I understand co-dnfs to be self-hosting, so maybe a toy programming language? [1] [this video]

Cites 9214 · 2019-11 · on “The 80/24 Rule”

Old Forths with block-based I/O used 64/16 (so that definition takes ≤ 4096 bytes and fits into disk block). Makes no sense in the modern world of course, but, in the context of block editors, it creates a development environment where making complex and bloaty word definitions is actively discouraged -- an idea that Aaron Hsu briefly mentions in his APL talks [1]. [1]: [this video]

Cites sctb · 2023-08 · on “Modernizing Compiler Design for Carbon Toolchain [video]”

Thanks for the link! I just found the one I was thinking of, which is older but perhaps goes into more detail: [this video] .

Cites tom_ · 2025-11 · on “Learning to read Arthur Whitney's C to become smart (2024)”

Possibly related(ish): video about co-dfns, prompted by a previous HN thread (links in video summary), not written in C but put together in a similarly dense style: [this video]