Jupyter Notebook

A Jupyter notebook is an interactive, document-based coding environment that interleaves executable code, its output (including plots and tables rendered inline), and formatted text explanation in a single file — a format that grew out of IPython, an enhanced interactive Python shell created by Fernando Pérez in 2001, and was spun off and generalized into the language-agnostic Jupyter project in 2014 (the name itself an acronym for Julia, Python, and R, the three languages the project initially targeted support for, though it has since expanded to support dozens more). The core unit is the cell: a block of code or text that can be executed and re-executed independently, with its output displayed directly beneath it, which is the feature that distinguishes a notebook from both a plain script (no inline output or narrative) and a static report (no executable, re-runnable code).

The cell-based, non-linear execution model is simultaneously the notebook's greatest strength for exploratory work and its most frequently criticized weakness for reproducibility: cells can be run in any order, multiple times, independently of their position in the document, which makes rapid, iterative exploration of data extremely fluid but also means a notebook's visible, saved state can silently diverge from what would actually happen if every cell were re-run in top-to-bottom order. A notebook where a variable was defined in cell 10, then cell 10 was later deleted or modified, can still show correct-looking output in cell 15 that depends on that now-missing definition — a well-documented and widely discussed failure mode, sometimes referred to as "hidden state," that has made notebook-based reproducibility a recurring subject of debate and tooling effort in the data science community, including guidance from Jupyter's own documentation recommending a full "restart and run all" before trusting a notebook's results.

Notebooks are widely used for exploratory data analysis, teaching, and communicating results, precisely because they combine narrative explanation and live, runnable code and output in a single shareable document — a data scientist can walk a colleague or a stakeholder through an analysis step by step, with the reasoning, the code, and the resulting chart all visible together in one place, rather than needing a separate script and a separate write-up kept in sync manually. This same property makes notebooks poorly suited to production software, where code needs to run reliably, automatically, and in a fixed, predictable order with no human clicking "run" on cells one at a time — which is why production machine learning and data pipelines are almost universally built as ordinary scripts or modules, with notebooks reserved specifically for the exploratory and communicative phase of a project rather than deployed as the production system itself.

JupyterLab, released as the next-generation interface in 2018, extended the original single-notebook browser interface into a full, multi-pane IDE-like workspace (file browser, terminal, multiple notebooks, and other tools side by side), while Google Colab (launched 2017) and similar cloud-hosted notebook platforms removed the local-setup barrier entirely by providing free, browser-based notebook environments with GPU access, a significant factor in lowering the entry barrier to running real machine learning experiments without owning specialized hardware.

Version control for notebooks remains a genuinely harder problem than for plain code, because a notebook's underlying file format (.ipynb) is JSON containing both code and cell output (including binary image data for plots), which makes diffs in a standard version control system like Git noisy and difficult to review compared to a plain text script — a problem specialized tools like nbdime and nbstripout exist specifically to address, either by producing more meaningful notebook-aware diffs or by stripping output before committing, neither of which is a universal default, which is why notebook diffs remain a recurring point of friction in collaborative data science work even with these tools available.

Read a Jupyter notebook as a document built to merge the exploratory immediacy of a REPL with the narrative capability of a written report: the same cell-based, re-runnable design that makes it ideal for iterative exploration and teaching is exactly what makes it unreliable as a production artifact and awkward to track cleanly in version control, which is why the field has converged on a fairly consistent division of labor — notebooks for exploring and explaining, plain scripts for anything that actually has to run reliably in production.