How god works

Everything so far has been the grammar. This part is the machinery underneath, and it matters because it is what you lean on at the edges: when the vocabulary runs out, when the table is somewhere else, when something is wrong.

The chapters run outward. Nothing runs until you ask for it, which is the first chapter and the fact every other one stands on. Any pipeline will print itself back in a language you already use. That is the way out when the vocabulary does not cover what you need, and the reason adopting a small grammar is safe: the exit is part of the design. A table that lives in a warehouse can be read where it sits, and the same sentence runs there unchanged. Any pipeline will also draw what it does to the table, step by step, before it runs any of it. That is where you find out that the column you are missing was taken away four lines up. And when something is wrong, the whole pipeline is checked before any of it runs, so a refusal names the step you wrote rather than the middle of a query you did not.

Three spellings of one grammar: R with its pipe, Python with its pipe, and the plain text form, all building the same plan. One checker reads the whole plan before anything runs. From there the plan is either executed, on DuckDB or Spark, or printed as SQL, Spark SQL, dplyr, pandas, polars or PySpark.

The machine, whole: three spellings build one plan, one checker reads it, and every backend writes it out.

One law holds the part together: nothing runs until you ask, and its other half is that every refusal is the grammar’s. The first half is what makes a pipeline safe to build in pieces. The second is what makes an error message useful, because one voice wrote all of them and every one names what to do next. The laws behind the whole vocabulary are collected at the end of the part, each with the temptation it exists to refuse.

Read this part if you are deciding whether to depend on god. It is where the claims made in the preface are demonstrated rather than asserted.