How We Planned a Book in Parentheses

It started, as the best things do, with Duncan casually dropping a bomb mid-conversation.

We'd been deep in the weeds of lykn's AI infrastructure -- concept card extraction, JS guide generation, SKILL.md files for Claude Code -- when he pivoted: "Until then, I thought you and I might start planning something further downstream... and maybe even more exciting. Our own lykn book!"

He'd already been extracting knowledge from four JavaScript books he owned (Exploring JS, Deep JS, Eloquent JS, JS: The Definitive Guide), turning them into hundreds of concept cards with Claude Code's help. The cards were originally meant to train CC on JavaScript well enough to write idiomatic lykn. But Duncan saw further: what if those same cards became the curriculum for a book?

And then, the kicker: "Since this is a fun, goofy language, I thought we might be able to do it in a rather wacky voice. Maybe the cast of Monty Python, or some such."

The First Sketch

A Lisp-flavoured JavaScript with Monty Python narration? There's nothing else like that in the programming language book space. We had the ingredients: 25 Decision Documents defining every syntax choice with rationale and rejected alternatives, five research papers on Lisp history and JS hazards, and a growing library of concept cards.

The first Table of Contents came together fast -- 31 chapters across 8 parts, each tagged with a Monty Python sketch reference. The key structural insight: the book should follow the DD dependency order. DD-01 (colon syntax) comes before DD-02 (functions) because functions use colon syntax. DD-06 (destructuring) comes after DD-02 because destructuring appears in function parameters. The implementation order is the teaching order.

1,576 Cards Walk Into a ToC

Then the concept cards arrived. All 1,576 of them.

Duncan had been running Claude Code through his JS books for weeks, extracting atomic concepts -- one card per idea, each tagged with its source book. Some concepts appeared in all four books (type coercion, closures, promises); others were unique to one source.

The mapping session was intense. 1,370 cards placed across 31 chapters. The heaviest chapters were immediately obvious: Browser/DOM had 117 cards (Eloquent JS's project chapters contributed an enormous amount of DOM knowledge). Functions had 85 cards from four books all going deep on closures, scoping, and higher-order patterns. Objects had 76 cards because Deep JS alone dedicates 40 cards to copying, freezing, and shared mutable state.

The Language Kept Evolving

Between the first ToC sketch and the detailed mapping, the language itself had changed dramatically.

Lykn had split into two layers: lykn/kernel (the original s-expression-to-JS compiler) and lykn/surface (a new functional language with bind, func, fn, type, match, cell, and contracts). Nine new DDs had been written covering macros, algebraic data types, pattern matching, threading macros, and a Rust-based surface compiler.

The book needed a v2 ToC. But the core insight held: the concept cards still mapped to the same topics. What changed was the framing. The early chapters needed a "two worlds" introduction -- kernel syntax (what JavaScript understands) vs surface syntax (what you actually write). The v2 ToC landed at 37 chapters across 9 parts, plus 9 appendices.

Finding the Voice

Duncan's original instinct -- "maybe Monty Python" -- was right, but we needed to figure out how.

Pure Monty Python would be too random, too sketch-comedy. A programming book needs to teach, not just entertain. We landed on "Scholarly Shenanigans": Terry Pratchett (50%), Douglas Adams (20%), P.G. Wodehouse (20%), Monty Python (10%). A narrator who takes the material seriously while finding it genuinely funny -- not a comedian who happens to mention code.

Each chapter opens with a Monty Python sketch adapted to the chapter's technical concept. Not a random sketch -- a mapped sketch, where the comedy illuminates the programming concept:

• The Spanish Inquisition keeps returning across Part III (strings, colon syntax, mutation) because nobody expects the features that keep showing up
• The Knights Who Say "Ni!" sustain all of Part IV (data structures), demanding objects, then arrays, then classes, then iterators -- becoming better engineers with each demand, until they run out of demands and fall silent
• The Bridge of Death recurs whenever the reader faces a gatekeeping mechanism (the iteration protocol, linter configuration)
• "How Not To Be Seen" is the compiler chapters -- the kernel compiler has been hiding behind the surface language for 30 chapters, and now we ask it to stand up
• The Dead Parrot opens Chapter 0: JavaScript's hazard landscape ("This language is no more! It has ceased to be well-designed!")
• The Holy Hand Grenade for arrays ("First shalt thou count to three. No more. No less.")

The title itself: "And Now for Something Completely Parenthetical." A Lisp compiler inside a <script> tag -- parentheses compiling to semicolons, in the browser, at page load. The title waits 32 chapters for its punchline.

The Prompt Factory

With the ToC, concept card mapping, voice guide, and sketch references all in place, we needed a way to actually produce 37 chapters. Each chapter got a self-contained Claude Code prompt containing the authoring guide, chapter structure with word count targets, prioritized concept card lists, research documents, and technical notes.

We generated all 37 prompts across two sessions. The cadence was relentless -- one prompt every few minutes, with Duncan calling "19!" and me building the prompt. The running score kept us both engaged: "24 done, 13 to go. Past the halfway mark!"

Design Under Pressure

Halfway through the second session, something unexpected happened. Claude Code, implementing changes in a parallel terminal, hit a bug: destructured parameters didn't work in surface func forms. We paused prompt generation and designed DD-25 right there.

Then CC found another gap: top-level (default ...) and (rest ...) didn't work in :args outside destructuring patterns. We designed DD-25.2. Duncan pushed back on one detail -- I'd proposed deferring per-element type checking for typed rest parameters, and he asked simply: "Why don't you want to do the per-element type-checking now?" He was right. It was a for-of loop wrapping a buildTypeCheck call that already existed. Ten lines of code. I'd been pattern-matching on frequency rather than difficulty.

This was the collaboration at its best: design conversation leads to a Decision Document, which leads to an implementation prompt, which leads to CC execution, which surfaces a bug, which leads to a new DD, which updates the prompts. The book planning drove language design improvements.

The Quality Pipeline

Every chapter prompt includes a code verification requirement: every code block gets a companion test. Compilation tests (lykn source compiles to expected JS), execution tests (compiled JS runs correctly), and failure tests (compile errors fire when they should). Console output tested via monkey-patching. Tests run in CI -- broken examples break the build.

The philosophy: a programming book with untested code examples is a programming book with bugs.

The Score

Two sessions. 37 chapter prompts. 3 new Decision Documents. 1,576 concept cards mapped. Every chapter has its sketch, its structure, its word counts, its card triage, its research docs, and its technical notes.

And as of last night, the first draft of the book has been completed. Duncan's even had the idea of turning it into a secret coffee table book with the addition of nearly 40 art pieces at the beginning of every chapter. Just because.

Next up: we've registered lykn.pl and we're building (will have built) the site (by the time) you're reading now.