Deterministic Core, Non-Deterministic Shell

3 Aug 2026

Fourteen years ago, Gary Bernhardt coined the term Functional Core, Imperative Shell . Like most fine ideas in computing it was not entirely new, but his concept had awesome clarity, and it forms an outstanding basis for talking concerning evaluation and determinism in existing systems.

Briefly, Functional Core/Imperative Shell architecture divides the code into two parts. The Functional Core is purely functional - that is no IO, and no destructive province updates. It is concerned alongside the endeavor logic of the application. The Imperative Shell has comparatively small pathing, but maintains state, coordinates external dependencies, and deals alongside the outside earth - that is to say IO. Its job is to query the center alongside values, receive values rear as the outcome of several blackbox decision, and use that to interact alongside the exterior world; whether that's penning to a database, sending a request, or updating a GUI.

The Shell and the Core in this example have distinct characteristics:

This makes the center extremely amenable to testing. Since it's purely functional, the identical inputs volition continually get the identical results. Since it's isolated, there is nothing to imitate or stub. And since it handles complex endeavor logic, the tests can inform us a lot concerning how the scheme behaves.

Functional Purity and Determinism

A shorter way of describing the properties that create clean functions amenable to evaluation is that they are deterministic. That is - stated a stream of inputs, a clean function continually returns the identical stream of outputs; their behavior is repeatable. But clean functional programming is not the lone way to get there. If we tilt our heads a small we can see that a stream of values and a sequence of assignments are different ways of expressing the identical thing, and State Machines can bring us the identical benefits. Consider the following code:

 function add(ns) { return ns.reduce((a, b) => a + b, 0) } class AddMachine { #state = 0 transition(input) { this.#state += input } get state() { return this.#state } } 

The function add is uncomplicated to logic about; it's clean and thus deterministic. But the AddMachine is additionally deterministic - given the identical sequence of calls to the passage function, AddMachine volition come back the identical state. It being imperative does not alter that.

 const output = add([1, 2, 3]) 

 const a = new AddMachine() a.transition(1) a.transition(2) a.transition(3) const output = a.state 

Pure functional programming is a fine paradigm, but because of tongue or achievement considerations, it is not continually applicable - I would not desire to try it in C! But weakening the requirements from purely functional to merely deterministic, we keep the testability benefits of "Functional Core, Imperative Shell", during broadening its applicability. And so the title of this post: Deterministic Core, Non-Deterministic Shell.

Determinism can awareness akin a additional theoretical idea than functional purity. How do you cognize it whenever you see it? I discover it's easier to commencement alongside what is not deterministic and activity backwards. Here are several average examples of non-repeatable behaviour:

• Calling RNGs that aren't seeded
• Asynchronous and multi-threaded operations
• Communication complete the network
• Communication alongside another processes
• Reading/Writing to local storage
• Database interactions
• Asking the OS for the date or time

All these pertain in the non-deterministic shell. Whenever you discover them in your endeavor logic, you have a natural mark for defragmentation - either splitting the function in two about them, or lifting them up a tier and injecting their outcome as a parameter. It's explanatory to think of the "shell" metaphor fairly literally; it should encircle the logic, querying the bosom of the use to get what it needs.

Working alongside what you have

"This is all fine and good", you power think, "but what use of it is to me, toiling distant in the bequest & vibe-code mines of industry?". A fair accusation, imaginary reader; not everyone can be Foundation DB and create that difference from day one (they really went a stage further, but that's a topic for another post). Determinism and non-determinism are extremely entwined in nearly all genuine life codebase I have seen, and I've seen my fair share.

But don't let ideal be the enemy of good! One way to think of your average (ie, terrible) codebase is that it has many deterministic cores. There are thousands, strewn through the slop as stars in the sky. The pane fractional empty obtain is these codebases are an irredeemable bequest mess. But pane fractional full is that there are many deterministic cores hidden location inside, and maybe lone a handful.

Users of older Windows systems may recall the "Disk Defragmenter"; it took records whose contents were scattered physically throughout the spinning difficult disk and made them contiguous. In an era anywhere peruse speed depended on physical extend on the media, this mattered a lot.

So one gradual method for existing code is to custom the Defragmentation of Determinism. Identify it anywhere you can - files, classes, equal a few lines in idiosyncratic functions - and commencement collecting them. The more determinism that can be grouped, the additional effortlessly testable functionality you have, and the additional you can awareness assured concerning the behavior and reliability of the program as a whole. The exterior area for "hard to test" (non-deterministic code) starts to shrink. On a ample adequate codebase you will apt never get to a sole deterministic core, but equal hundreds is better than thousands.

Unleash the State Machine Within!

Every nasty disorder of a codebase I've seen has one or additional much nicer deterministic province machines locked inside. I commitment you they are there, even if it's not obvious. And formerly you discover them, you'll be delighted alongside how much easier the application is to modify and test. Piece by piece, reliability can be wrought.