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.
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 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.
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.
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).
great work the world needs more of this!