This talk explores the following question: What would it take to create a new kind of Python notebook that, unlike a REPL, knew the order in which to run cells? What if the notebook could also update automatically or lazily when a variable was updated? And what if we could add UI elements, like sliders and dropdowns, to all this? Would this change how you worked with notebooks?
But most of all: how would you build such a thing? In this talk, we propose that you would need a kind of "compiler" on top of Python.
This talk focuses on how to create such a notebook by using marimo — an open-source reactive notebook for Python that's executable as scripts and shareable as apps — as a case study. Marimo's key technology is static analysis: marimo "compiles" blocks of Python code, or "cells", to a directed acyclic graph. This graph models how data flows across cells, and is used as an intermediate representation consumed by a runtime that eliminates hidden state while also powering interactive computing, scripts, and web apps.
By using notebooks and marimo's internals as a case study, we'll examine a question that is broadly applicable to developer tools in many domains: What does it take to compile Python code to a flexible intermediate representation that preserves the original program's semantics? We'll discuss design decisions and tradeoffs along the way, such as the pros and cons of static analysis versus runtime tracing.