I think the main insight from "functional core, imperative shell" is more about structuring the code so as to be easy to test.
Without that structure, code tends to be difficult to test, since the impure stuff like network requests is part of the same sequence of statements as the logic you want to test. (That is: pure code is easier to test (but harder to write real programs with).. so, "arrange the code so you've got a well tested core" is a good strategy).
The nice part about the pure/functional is that you know for the same inputs, you always get the same outputs. -- I think if you want to say, "well, this stateful object is still pure (if you consider the state part of the input" then sure, I guess.
Correct. FCIS is about testing. Testing pure code is a lot easier than testing impure code, but most of what you want to implement can be done with pure code, and you can isolate the impure code to a shell that can be tested apart from your pure business logic.
I think actions vs calculations is a better framing here. It's not just about avoiding imperative code or nondeterminism. It's about being extra careful with actions because the order and number of times they run matter.
Here is an example of a calculation written imperatively. It remains easy to reason about because the actions don't leak out of the function:
function add(ns) {
let total = 0
for (const n of ns) {
total += n
}
return total
}
On the other hand, a deterministic state machine like `a = AddMachine` is harder to reason about because it still matters how many times the action `a.transition(1)` is called. (Note it is possible to implement the state machine as calculations.)
I agree with the thrust of the article but I want to quibble with one thing: the article says “calling RNGs that aren't seeded” doesn’t count as deterministic behavior, but randomized algorithms often have simpler implementations and better asymptotics than non-randomized algorithms while having statistical guarantees (“almost surely”) on their properties. Two of my favorite examples: (1) a randomized quicksort where choosing the pivot randomly in each iteration is simpler and better than deterministic methods of choosing the pivot; (2) a randomized treap gives you a balanced binary search tree with far simpler implementation than say a red black tree. And that’s besides the more utilitarian security benefit of using randomness inside hash functions to protect against HashDoS attacks.
So I’d implore the author to delete this restriction. Even when randomized algorithms produce different outputs (the treap giving you differently shaped trees with the same sequence of inserts) these outputs have properties that can be checked statistically.
Anything you can do with ""real"" randomness can be done just as well with a seeded [CSP]RNG, including DoS prevention if you can keep the seed secret.
If you really want true RNG, you can inject a deterministic RNG at test-time and use a real one otherwise.
Great, that’s the ideal case. But in many languages and many libraries it is all but impossible to pass on a seed to everything that uses randomness, unless you control all these libraries.
That’s why as a matter of practicality I’d advocate otherwise.
If you want to avoid the word 'functional' then say pure: pure core, impure shell. Or maybe: pure core, I/O shell. Otherwise it's too long :)
Idk. I like Gary's formulation. No, I love it. One time when designing an STS with Claude I told it my FCIS design for an STS and Claude demonstrated real excitement -- it really loved the idea.
Briefly, my idea was to have the functional core isolated such that it receives a JSON description of the input request, any additional data [wait for it], and outputs either: an error, a request for more data, or a description of a token/credential to issue and with what issuer credentials. This would allow one to write all the core logic in Julia, JS, MicroJS, jq even, any language you like, and the imperative shell is what does all the rest (authentication, token validation, database lookups -- whatever you want). I swear Claude expressed real excitement over this. I've seen Claude be frustrated as well. It really does seem to have some sorts of emotions.
Sounds very similar to the "interpreter" or "virtual machine" pattern (can't recall the exact name).
But essentially a component receives a list of high level instructions / description of what the user wants done, and it translates that into descriptions of "lower level" commands that should be performed. And those commands then get executed separately.
Anythinf statefule / io is contained in the commands and can be tested easily with external dependencies. And the complex logic is all pure in decided what to do and how to do it based on what was asked for.
Its interpreters all the way down. Going up the stack is finding the right Domain Specific Language to describe the self modifying sociotechincal business process computer that is capitalism
I've been pondering something I call "slop core, artisanal shell", as a way of keeping vibecoding under control. Slop core might sound like the thing you want to avoid, but as long as it's purely-functional (or perhaps, merely deterministic) it should be robustly testable. The "artisanal shell" keeps the thing human-understandable and human-modifiable, as long as you put some thought into the API boundaries.
I have been trying to tell the folks at work the same thing. Ideally, using a language that goes in that direction. For frontend web development, for example, there is Elm, which is pure and functional.
I think the main insight from "functional core, imperative shell" is more about structuring the code so as to be easy to test.
Without that structure, code tends to be difficult to test, since the impure stuff like network requests is part of the same sequence of statements as the logic you want to test. (That is: pure code is easier to test (but harder to write real programs with).. so, "arrange the code so you've got a well tested core" is a good strategy).
The nice part about the pure/functional is that you know for the same inputs, you always get the same outputs. -- I think if you want to say, "well, this stateful object is still pure (if you consider the state part of the input" then sure, I guess.
Correct. FCIS is about testing. Testing pure code is a lot easier than testing impure code, but most of what you want to implement can be done with pure code, and you can isolate the impure code to a shell that can be tested apart from your pure business logic.
I think actions vs calculations is a better framing here. It's not just about avoiding imperative code or nondeterminism. It's about being extra careful with actions because the order and number of times they run matter.
Here is an example of a calculation written imperatively. It remains easy to reason about because the actions don't leak out of the function:
On the other hand, a deterministic state machine like `a = AddMachine` is harder to reason about because it still matters how many times the action `a.transition(1)` is called. (Note it is possible to implement the state machine as calculations.)https://ericnormand.me/podcast/what-is-an-action
https://livebook.manning.com/book/grokking-simplicity/chapte...
I agree with the thrust of the article but I want to quibble with one thing: the article says “calling RNGs that aren't seeded” doesn’t count as deterministic behavior, but randomized algorithms often have simpler implementations and better asymptotics than non-randomized algorithms while having statistical guarantees (“almost surely”) on their properties. Two of my favorite examples: (1) a randomized quicksort where choosing the pivot randomly in each iteration is simpler and better than deterministic methods of choosing the pivot; (2) a randomized treap gives you a balanced binary search tree with far simpler implementation than say a red black tree. And that’s besides the more utilitarian security benefit of using randomness inside hash functions to protect against HashDoS attacks.
So I’d implore the author to delete this restriction. Even when randomized algorithms produce different outputs (the treap giving you differently shaped trees with the same sequence of inserts) these outputs have properties that can be checked statistically.
Anything you can do with ""real"" randomness can be done just as well with a seeded [CSP]RNG, including DoS prevention if you can keep the seed secret.
If you really want true RNG, you can inject a deterministic RNG at test-time and use a real one otherwise.
Easily circumvented: Generate a random seed in the shell and pass it to the core.
Great, that’s the ideal case. But in many languages and many libraries it is all but impossible to pass on a seed to everything that uses randomness, unless you control all these libraries.
That’s why as a matter of practicality I’d advocate otherwise.
If you want to avoid the word 'functional' then say pure: pure core, impure shell. Or maybe: pure core, I/O shell. Otherwise it's too long :)
Idk. I like Gary's formulation. No, I love it. One time when designing an STS with Claude I told it my FCIS design for an STS and Claude demonstrated real excitement -- it really loved the idea.
Briefly, my idea was to have the functional core isolated such that it receives a JSON description of the input request, any additional data [wait for it], and outputs either: an error, a request for more data, or a description of a token/credential to issue and with what issuer credentials. This would allow one to write all the core logic in Julia, JS, MicroJS, jq even, any language you like, and the imperative shell is what does all the rest (authentication, token validation, database lookups -- whatever you want). I swear Claude expressed real excitement over this. I've seen Claude be frustrated as well. It really does seem to have some sorts of emotions.
Sounds very similar to the "interpreter" or "virtual machine" pattern (can't recall the exact name).
But essentially a component receives a list of high level instructions / description of what the user wants done, and it translates that into descriptions of "lower level" commands that should be performed. And those commands then get executed separately.
Anythinf statefule / io is contained in the commands and can be tested easily with external dependencies. And the complex logic is all pure in decided what to do and how to do it based on what was asked for.
FCIS is basically that. You don't need an interpreter/VM, but that is an option.
Its interpreters all the way down. Going up the stack is finding the right Domain Specific Language to describe the self modifying sociotechincal business process computer that is capitalism
This split is familiar from Temporal.io: workflows are deterministic while activities are idempotent.
I wonder if languages could and should allow enforcing both properties.
For frontend web development, Elm enforces a pure core (pure > deterministic).
[dead]
I've been pondering something I call "slop core, artisanal shell", as a way of keeping vibecoding under control. Slop core might sound like the thing you want to avoid, but as long as it's purely-functional (or perhaps, merely deterministic) it should be robustly testable. The "artisanal shell" keeps the thing human-understandable and human-modifiable, as long as you put some thought into the API boundaries.
I have been trying to tell the folks at work the same thing. Ideally, using a language that goes in that direction. For frontend web development, for example, there is Elm, which is pure and functional.
great work the world needs more of this!
[flagged]
[dead]