An O(x)Caml book that runs

An O(x)Caml book that runs 13 Jun 2026I am building a course, “Functional Programming with OCaml”, for the NPTEL MOOC platform: twelve modules of recorded lectures. The course book is not a PDF and not a website with code listings you copy elsewhere. It is a website where the code runs, in your browser, with nothing installed and no server behind it. The first half is OCaml; the last few modules cross into OxCaml. An O(x)Caml book, and one that runs. This post is about why I built it that way, how I wrote it (with a lot of help from an LLM, under careful review). It is also a call for feedback: if you have ideas for how to make the course better, or if you find any bugs in the material, please let me know. The course is still evolving, and I want to make it as good as I can for the students who will be learning from it. Zero to OCaml in zero steps The single biggest obstacle a beginner hits with any language is not the conceptual understanding. It is the install. OCaml has gotten much better here over the years. The OCaml Platform extension for VS Code will install a compiler toolchain for you, and the dune build system and the opam package manager have all worked seamlessly together for years now. But that is the experience for someone who already knows they want VS Code, knows what a switch is, and knows what to do when a step does not go as the happy path describes. For a beginner, the path from “I have a laptop” to “I ran my first OCaml program” still has non-trivial steps, and the failure modes are exactly the ones a beginner is least equipped to debug. I have lost count of the hours spent at the start of hands-on workshops just getting OCaml onto people’s machines. Anil Madhavapeddy once told me that he and Yaron Minsky spent almost the entire session of their 2013 CUFP OCaml tutorial getting OCaml installed on attendees’ laptops. I have done my share of the same, walking a room through opam , and more than once apologising for the state of Windows support. That last apology I no longer have to make, thanks to the opam team’s work over the past few years (see the opam 2.2.0 alpha announcement on native Windows). I have had my own forays into fixing the broader problem: OCaml Jupyter notebooks wrapped in a Docker container (I wrote about teaching with Jupyter notebooks years ago, and that is how I taught CS3100), and more recently devcontainers for workshops. The OxCaml ICFP tutorial and our learn-ocaml workshop materials both lean on containers too. These work, but only in the right setting. In a classroom where people can spend a couple of hours getting dependencies in place, fine. On conference wifi, for a two-hour tutorial, downloading a devcontainer or a Docker image takes all the fun out of programming before any programming has happened. What I wanted was zero to OCaml in zero steps. No install. And, just as importantly, no servers for me to administer. But still a seamless experience where a learner can change code and execute it. You are reading the book right now, in a sense. Here is a live cell. If you are in a browser, there is a Run button near the top right. Click it. Change "reader" to your own name and run it again. The OCaml toplevel just ran in your browser. No server, no install, and the bytes never left your machine. Why purely client side The best thing about programming is that you can poke at it: change something, watch how it reacts, and learn from the reaction. Books cannot be poked. The usual fix is to read with an editor open alongside and type things in, but that always feels slightly off, because the book cannot assume you are playing along. It has no way to know you have the same compiler version, the same libraries, the same anything, so the interactive part drifts out of sync with the prose. I wanted the opposite: a book that assumes you are playing with it, because the playground is built into the page. Where this course lives makes that matter even more. NPTEL is a MOOC; I never meet the students and there are no dedicated labs. A student might be on a laptop shared with a parent, on Windows 11, on a tablet with an external keyboard, or on some machine you would not expect to still be in use and that OCaml very likely does not support. Around 170 people have enrolled so far, and I do not want a single one of them to give up on OCaml over an installation problem in the first hour. So the book is purely client side. The website is the textbook: There is no separate textbook to buy or download. Every lecture in this course is also a page on the course website, and the slides you see in the videos are excerpts from those pages. The website is the book: the same material, expanded into prose, with the examples runnable in place and the quizzes interactive. Open it in any browser; no login, no install, nothing to download. None of the individual pieces are new. Running OCaml in the browser has been possible for years: the official playground at ocaml.org, TryOCaml, sketch.sh, and x-ocaml itself, which this book is built on. What I think is new is putting the pieces together: one course where the prose, the slides, the runnable cells, and a full Linux machine are the same thing, with tooling that keeps them correct and consistent. The rest of this post is about how. One source: page, slides, cells There is a second reason the page matters as much as the video. When I teach CS3100, the executable notebook is the slide deck, thanks to the RISE extension that turns Jupyter cells into a reveal.js presentation. Students ask questions, and I answer them by live coding in the same surface I am presenting from. This book rebuilds that idea, but purely in JavaScript. One markdown source produces the lecture webpage, a reveal.js slide deck, and the runnable cells, all from the same file. Since NPTEL videos show only the slides, the slides have to carry the full content, and because they are generated from the same source as the prose, they cannot drift away from it. More on that machinery below. How it is built: two tiers Under the hood there are two tiers of execution. The light tier is the cell you ran above. It is the x-ocaml WebComponent (Arthur Wendling’s work), an OCaml 5.4 toplevel compiled to JavaScript with js_of_ocaml . What makes it feel like a real editor rather than a text box is that Merlin runs inside it, in a Web Worker: hover over any expression and you get its inferred type, you get autocompletion as you type, errors are reported inline, and ocamlformat will tidy the code on request. Scroll back up and hover over greeting in that first cell; the type appears without your running anything. It all runs entirely in the tab, your edits persist in local storage, and the whole functional-programming half of the course lives in cells like it. I have written before about embedding x-ocaml in a blog; this course is what that experiment grew into. The heavy tier is for when a toplevel is not enough. To run a test suite, measure coverage, compile and run a C program, or build and boot an operating system, you need a real project on a real machine: dune , several files, a test runner, a C compiler. So the later modules embed a full 32-bit Alpine Linux machine that boots inside the browser tab, using the v86 x86-to-wasm emulator. It resumes from a compressed snapshot rather than cold-booting, serves its filesystem lazily over 9p (you download only the chunks your commands actually touch), and ships with OCaml 5.4 bytecode, dune , and gcc preinstalled. It is about 12 MB to an interactive shell. The promise, quoting the course intro, is the same as the cells: nothing is installed on your computer and nothing runs on a server; the entire machine runs in the page. Here is one, embedded in this post exactly as it appears in the course. Click Start, wait a few seconds for the snapshot to load, and you land at a shell in a hello project. Try ls , or dune exec ./hello.exe to build and run it, or cat hello.ml . It is a real Linux machine, booting in this tab, fetching the disk image on demand from a CDN; nothing is installed on your computer. A student can compile and run real C, or boot a unikernel, on a shared Windows laptop with nothing but a browser tab. The two tiers trade off very differently, and not only on size. The light cell is OCaml compiled straight to JavaScript, so once the one-time bundle has loaded (about 17 MB gzipped, then cached by the browser) it runs at JavaScript speed. The VM is the opposite. You are running OCaml bytecode inside a Linux guest inside an x86 machine emulated in WebAssembly, several layers of emulation deep, so it boots in a few seconds and then runs noticeably slower than a real machine would. That is why the light tier carries most of the course and the VM comes out only where a real build genuinely needs it. In both cases “zero install” means nothing is left on your machine, not that nothing is downloaded. How I wrote the course: teaching the model how to teach I have recorded video lectures for CS3100, my “Paradigms of Programming” course at IIT Madras (the lectures are on YouTube). The pipeline that turns those into drafting material is in the repo: yt-dlp pulls each video from that playlist, ffmpeg extracts the audio and uses scene detection to pull out the slide stills, a local Whisper model (run on my laptop via Apple’s MLX) transcribes the audio, and a small script aligns each slide with the narration spoken while it was on screen. The output is a drafting view that pairs every slide image with, in my words, what I said about it. That is a good starting point for a chapter: the model can see the slide and read the explanation. The first drafts were rougher than I expected. The content was all there; what was missing was the pedagogy. The bigger problem was that the model found it hard to introduce only as much as a module needed and nothing more. It kept jumping to concepts that are either unfamiliar to the typical student or that belong to the