Notlob is a new language for literate programming by human and machine agents. It promotes natural language context from prompts lost in chat history, or comments discarded by the compiler, to first class structures in code. It aims to let code be written with the grounding and clarity of a good technical report, supported by properties and examples which are themselves executable code.

It looks like this:

#Pricing Discounts

A discount strategy applies a multiplier to a price, yielding a reduced
price. Strategies are values in [0,1] representing the proportion of the
price to retain. A value of 1.0 means no discount; 0.0 means free.

    def apply_discount(strategy: Decimal, price: Decimal) -> Decimal:
        return price * strategy

~example
    apply_discount(Decimal('0.8'), Decimal('100')) == Decimal('80')

(Excerpt; full program here.)

As well as being a working programming language, notlob also provides infrastructure for reuse and consistency across a codebase. Headings and symbols are treated as nodes in a name-graph. This provides a data structure for checks, and an IDE-like toolset for machine agents.

I have a new paper describing the language, now released as a preprint, and a working implementation with a number of example programs.

The animating idea is that a piece of software needs some continuing account of what it is for. This might be in human memory, encoded in social interactions with users, captured in unit tests and issue systems, written in specifications, scribbled in whiteboard sketches, or inscribed in explicitly written specification documents. In Peter Naur’s terms, it needs a theory. His retrospectively famous description is that Programming Is Theory Building, and to Naur that theory lives almost exclusively in the programmer’s head. LLMs, especially their dependence on the context window, complicate this. As Dominic Fox puts it,

These matters are brought to a head somewhat by the experience of programming with LLMs, because the LLM’s problem is that it lacks a theory of the program it is confabulating (and so tends to extend it in aberrant ways), but its singular mechanical competence lies in being rather inhumanly good at following the theory-traces within the codebase it’s working on (much as it’s also rather inhumanly good at decoding modernist poetry) .

Notlob’s response is to look to Knuth’s literate programming to program with literate machines. Well-written prose carries a theory, so make it easy to organise code in a documentary style. Make it cheap[er] to keep context and code in synch, explaining one another, by making them adjacent in two dimensions: the serial organisation of source code files, and the graph organisation of compiled program structure. Lastly, make it easy to reuse the vast existing corpus of software libraries by making the executable layer a choice of existing languages like Python and Haskell.

Whether or not we are in a renaissance of literate programming, as a recent paper claims, we are definitely and suddenly awash in executable natural language. Notlob revives an older structure for explaining ideas and makes it executable. It is for machines that can read like a human, but need concepts explained to them again and again and again.

References

Adam Burke (2026). A Literate Programming Environment for Human and Machine Agents. arxiv 2608.24644

Dominic Fox (2026). Holding A Theory. https://codepoetics.substack.com/p/holding-a-theory

Peter Naur (1985). Programming as theory building. Microprocessing and microprogramming, 15(5), 253-261.

Wuyang Zhang, Yansong Li, Zeyu Dong, Yu Wu, Yingyao Zhou, Duolei Wang, Songsirou Xing, Chichun Zhou, and Da Shen. 2024. Renaissance of literate programming in the era of LLMs: Enhancing LLM-based code generation in large-scale projects. arxiv 2502.17441