HackerTube.dev

Literate Programming in the Large

Next Day Video · 17.9K views · 2013-06-27 · 35:59

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

Timothy Daly, an original author of the Axiom computer algebra system, talks about turning a large Common Lisp codebase into a literate program. He argues code should be written as readable manuals, and the talk was given at Write the Docs 2013.

On Hacker News

HN recommends it in literate programming threads as a rare look at applying the idea to a huge, complex codebase, though some find it meandering.

Recommended by 3 HN people across 4 months · HN mentions 2014–2024

Topics

Software practice, open source & careersFunctional programming
Search by tags
literate programmingaxiomcommon lispdocumentationlegacy code

What people said

elviejo · 2017-05 · Recommendation

"Programs should be written for people to read, and only incidentally for machines to execute." (Structure and Interpretation of Computer Programs" by Abelson and Sussman) The idea is that you write a "Book" and the program is extracted, from the book. Literate Programming Wikipedia: [LINK] A nice talk about it: [VIDEO]

Read the original HN comment ↗
e12e · 2016-07 · Recommendation

There's a (somewhat rambling, but interesting) talk on the effort to rewrite the lisp symbolic math system Axiom[a] as a literate program (spanning several books) - precisely in order to make it possible to refactor and maintain the code: "Literate Programming in the Large": [VIDEO] [a] [LINK]

Read the original HN comment ↗
e12e · 2016-05 · Recommendation

I think there are two sound approaches to communicating complex systems between humans (which is the main goal here, a computer might be a bit slow compiling 200M LOC - but the real problem is that no human can read that much code, let alone understand it): 1) Write documentation that is also code. That is the idea of literate programming. I recently came across: "Literate Programming in the Large": [VIDEO] which is a bit of a wandering talk, but well worth watching: it talks about real, huge comolex systems, and how lp can help bring them back under control. 2) The other approach is to shift your perspective, so you don't have a complex solution to a compkex problem; but rather a few small and lightly connected straight forward solutions to simple problems. Now I doesn't matter if you're bad at communicating, because the ideas you try to convey are simple ideas. I think there are a few reason that STEPS appear to work: what we're doing with our complex software is simple stuff. If we know what we want to do (the hard part) doing so in a straightforward way becomes easy. If we can make hierarchies of abstraction and isolated sub-systems. Note that simple doesn't mean trivial. These solution often require quite a lot of theoretical education; but not an unreasonable amount.

Read the original HN comment ↗

Sources

Video by Next Day Video, 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