I’m not completely sure where I stumbled upon it, but I watched the Noise-based RNG GDC talk this Saturday morning.

In it Squirrel Eiserloh makes a case for using stateless hash functions for procedurally generated content.

There are some new capabilities this unlocks: the poster child example is procedurally generated terrain in a game like Minecraft: each 2D coordinate can have a stable terrain generated regardless of the player actions so far.

Later in the talk Squirrel asks the question, can we generate a PRNG out of a hash function?

The answer is yes: you wrap the hash function (hash(value: Int): Int) into a stateful wrapper rng(): Int which increments the hidden value everytime it’s called. Since hash functions possess the avalanche effect (tiny change in input causes a large change in the output), hash(0) should be wildly different from and unrelated to hash(1).

You end up with something like:

// What you originally had
uint32_t hash(uint32_t value) {
  return do_something_to(value);
}

// PRNG wrapper
static uint32_t position = 0;
uint32_t rng_next() {
    return hash(position++);
}

where a classic PRNG like Mersenne Twister or XorShift would look more like:

static state_t state = /* snip */;
uint32_t rng_next() {
    uint32_t value = read_value_from(state);
    advance(&state);
    return value;
}

Squirrel then claims the hash function based RNGs are more performant than the LCG ones in his measurements, which elevated the talk from a neat idea to “let’s test it out!”

Specifically, I want to implement Squirrel’s suggested hash function in Elm and compare it to the “official” Elm PRNG in terms of performance and randomness test batteries like Dieharder and TestU01.

All relevant code can be found in the repo Janiczek/elm-prng-20260802.

Squirrel’s hash function

In the GDC talk Squirrel gives his hash function on a slide:

unsigned int Squirrel3( int positionX, unsigned int seed )
{
    const unsigned int BIT_NOISE1 = 0x68E31DA4; // 0b0110'1000'1110'0011'0001'1101'1010'0100;
    const unsigned int BIT_NOISE2 = 0xB5297A4D; // 0b1011'0101'0010'1001'0111'1010'0100'1101;
    const unsigned int BIT_NOISE3 = 0x1B56C4E9; // 0b0001'1011'0101'0110'1100'0100'1110'1001;

    unsigned int mangledBits = (unsigned int) positionX;
    mangledBits *= BIT_NOISE1;
    mangledBits += seed;
    mangledBits ^= (mangledBits >> 8);
    mangledBits += BIT_NOISE2;
    mangledBits ^= (mangledBits << 8);
    mangledBits *= BIT_NOISE3;
    mangledBits ^= (mangledBits >> 8);
    return mangledBits;
}

Originally I wanted to port it directly, but then I found out he has published an updated version that should behave better. So let’s use that one.

Here is the relevant part:

constexpr unsigned int SquirrelNoise5( int positionX, unsigned int seed )
{
    constexpr unsigned int SQ5_BIT_NOISE1 = 0xD2A80A3F; // 11010010101010000000101000111111
    constexpr unsigned int SQ5_BIT_NOISE2 = 0xA884F197; // 10101000100001001111000110010111
    constexpr unsigned int SQ5_BIT_NOISE3 = 0x6C736F4B; // 01101100011100110110111101001011
    constexpr unsigned int SQ5_BIT_NOISE4 = 0xB79F3ABB; // 10110111100111110011101010111011
    constexpr unsigned int SQ5_BIT_NOISE5 = 0x1B56C4F5; // 00011011010101101100010011110101

    unsigned int mangledBits = (unsigned int) positionX;
    mangledBits *= SQ5_BIT_NOISE1;
    mangledBits += seed;
    mangledBits ^= (mangledBits >> 9);
    mangledBits += SQ5_BIT_NOISE2;
    mangledBits ^= (mangledBits >> 11);
    mangledBits *= SQ5_BIT_NOISE3;
    mangledBits ^= (mangledBits >> 13);
    mangledBits += SQ5_BIT_NOISE4;
    mangledBits ^= (mangledBits >> 15);
    mangledBits *= SQ5_BIT_NOISE5;
    mangledBits ^= (mangledBits >> 17);
    return mangledBits;
}

Repeating Squirrel’s point from the talk: to use this hash function as a PRNG, you’d pick a seed at the beginning, set position to 0 and increment it whenever the hash function was used. You can have multiple unrelated PRNGs by picking different seeds (or eg. hashing a game entity ID to be the initial seed).

I have ported it to Elm; the hash function converted to a PRNG can be found in src/Random/Squirrel5.elm. It’s of form State -> (Int, State) instead of () -> Int because Elm is pure and can’t hide side effects.

The numbers given by the Elm implementation agree with the C code’s output; same with all other implementations below.

JKISS32

I can’t recall which rabbit hole led me there, but somehow when reading about Dieharder etc. I have opened the paper “Good Practice in (Pseudo) Random Number Generation for Bioinformatics Applications”.

In it the author gives a few examples of their recommended PRNGs. Most are 64bit, but there is one working on 32bit numbers and only uses additions and shifts (no multiplications!), so let’s try it - it might be a lot faster than the multiplication-using ones? You never know.

Note: Why 32bit numbers? Elm doesn’t have access to (fast) 64bit integers, as it is compiled to JavaScript and JavaScript numbers are doubles (binary64 IEEE 754 floats). The maximum safe integer is 2^53 - 1, so we can’t quite reach 64bit integers.

Above that number, the doubles backing the JavaScript numbers get far enough from each other that 9007199254740991 + 1 === 9007199254740991 + 2.

The paper gives the following C code for the 32bit addition-only PRNG:

static unsigned int x=123456789,y=234567891,z=345678912,w=456789123,c=0;
unsigned int JKISS32()
{
    int t;
    y ^= (y<<5); y ^= (y>>7); y ^= (y<<22);
    t = z+w+c; z = w; c = t < 0; w = t&2147483647;
    x += 1411392427;
    return x + y + w;
}

My Elm implementation can be found in src/Random/JKISS32.elm.

Elm PCG - the status quo

There is a single “blessed” Elm random number generator library: elm/random.

There are multiple alternative PRNGs published on package.elm-lang.org but we’ll ignore them in this blogpost.

At least as of version 1.0.0, elm/random uses a variant of PCG (Permuted Congruential Generator), specifically the RXS-M-XS version (check section 6.3.4 in the PCG paper) with some custom decisions on how to initialize the RNG with just a single 32bit number instead of two.

If code-golfed to a minimal C code, the Elm’s algorithm could look like this:

typedef struct { uint32_t state, incr; } elm_seed_t;

static inline void elm_next(elm_seed_t *s)
{
    double product = (double)s->state * 1664525.0; // Spoilers...
    uint64_t truncated = (uint64_t)product;
    uint32_t word = (uint32_t)(truncated & 0xFFFFFFFFu);
    s->state = word + s->incr;
}

static inline uint32_t elm_peel(uint32_t state)
{
    uint32_t xored = state ^ (state >> ((state >> 28u) + 4u));
    double product = (double)xored * 277803737.0; // Spoilers...
    uint64_t truncated = (uint64_t)product;
    uint32_t word = (uint32_t)(truncated & 0xFFFFFFFFu);
    return (word >> 22u) ^ word;
}

static void elm_initial_seed(elm_seed_t *s, uint32_t x)
{
    elm_seed_t tmp = { 0u, 1013904223u };
    elm_next(&tmp);
    tmp.state += x;
    elm_next(&tmp);
    *s = tmp;
}

static inline uint32_t elm_step_random_r(elm_seed_t *s)
{
    uint32_t out = elm_peel(s->state);
    elm_next(s);
    return out;
}

There is a whole combinator library sitting on top of the next and peel primitives, doing some interesting bias-correcting math for returning random numbers in a certain range, but I’ll consider these out of scope. peel gives the “raw” bits that everything else is made of, and that will be what we compare against the other algorithms.

You might have seen the comment and the surprisingly complex code in the next and peel functions above. Doubles?! This is to emulate JavaScript behaviour: the Elm code is slightly buggy because of multiplying two 32bit ints in a naive way.

Multiplying two 32bit integers can produce a 64bit integer, and as mentioned above we don’t have those in the JavaScript world. The numbers we get back don’t fall on the nearest integer to the true result but get rounded to some multiple of 2^n depending on how large the result is.

The loss of precision means the current implementation of the PCG algorithm follows a slightly different trajectory for its internal state and the generated numbers than intended (than the canonical PCG algorithm would use for the given seed). I don’t know enough about these to explain how bad it is, but as we’ll see from the Dieharder results later, it does have an adverse effect on the randomness of the generated numbers.

JavaScript has a workaround for the 32bit multiplication: Math.imul(). We don’t have access to it in the Elm userland, instead we need to emulate it with bitwise operations like & and >>> (see imul32 in src/Bitwise/Extra.elm), resulting in compiled JS code similar to this:

function imul32(a,b) {
    var aLo = a & 0xFFFF;
    var bLo = b & 0xFFFF;
    var low = aLo * bLo;
    var aHi = a >>> 16;
    var bHi = b >>> 16;
    var high = ((aHi * bLo) + (aLo * bHi)) & 0xFFFF;
    return (low + (high * 0x10000)) >>> 0;
}

I only realized the bug is present when I ported the Elm PRNG to C and found it doesn’t give me the same numbers as the Elm version. Sure enough, it was that multiplication! When stepping through both implementations and comparing the numbers, I saw Elm give intermediate numbers like 5145799907274839000: way too big, and the 000 at the end was suspicious. (I see this routinely at work when webapps try to show big integers coming from Snowflake. Gotta love JavaScript.)

Changing the raw multiplications into an emulated imul32 fixed the issue. I have made a PR for elm/random (as we’ll see later, the gradual loss of precision does make a difference in the statistical tests) and continued with the exploration; though I expect the correct fix will be to rather add a new Bitwise.imul primitive to elm/core that will call Math.imul(), and use it from elm/random instead of the emulated version.

Here is how you probably expected the PCG C code from above to look:

 static inline void elm_next(elm_seed_t *s)
 {
-    double product = (double)s->state * 1664525.0; // Spoilers...
-    uint64_t truncated = (uint64_t)product;
-    uint32_t word = (uint32_t)(truncated & 0xFFFFFFFFu);
-    s->state = word + s->incr;
+    s->state = s->state * 1664525u + s->incr;
 }
 
 static inline uint32_t elm_peel(uint32_t state)
 {
-    uint32_t xored = state ^ (state >> ((state >> 28u) + 4u));
-    double product = (double)xored * 277803737.0; // Spoilers...
-    uint64_t truncated = (uint64_t)product;
-    uint32_t word = (uint32_t)(truncated & 0xFFFFFFFFu);
+    uint32_t word = (state ^ (state >> ((state >> 28u) + 4u))) * 277803737u;
     return (word >> 22u) ^ word;
 }

That is, use integer multiplication instead of doubles.

We’ll add two fixed PCG variants to the test suite and benchmarks:

1. One that uses the emulated imul32 (expressible in “userspace” 3rd party Elm packages)
2. One that uses Math.imul().

OK, enough talk about our contenders, let’s whip out the test batteries and see how random each implementation really is!

Dieharder

My initial attempt was to let Elm print a large amount of random numbers into a file, which I’d then pass to Dieharder with -g 202.

That’s not such a good idea: the tests need you to generate A LOT of randomness. 2^30 numbers (roughly 11GB in filesize) is not enough and taints the results. Dieharder automatically rewinds the file and sees the same numbers repeated, which causes some tests to fail.

Another approach was necessary. Dieharder has a mode -g 200 which consumes raw binary data from STDIN. That plus the fact that I wasn’t too impressed with the speed at which Elm printed the numbers, led me to use the C versions of the algorithms and port the Elm algorithm to C.

In the end I’m running Dieharder with the following flags:

$ ./jkiss32 | dieharder -k 2 -Y 1 -a -g 200
#                       ^         ^  ^^^^^^ load input from pipe
#                       ^         ^^ run all tests
#                       ^^^^^^^^^
#                       "Reduce Ambiguity" mode:
#           if WEAK, run more tests to end up at PASSED / FAILED

Full Dieharder reports are in the repository; here is the summary:

I don’t understand why Dieharder ignored some of the WEAK results, but the picture is pretty clear anyways: the current elm/random PRNG is statistically flawed due to the double multiplication bug. The other PRNGs don’t seem to have any apparent issues.

More testing is needed. Introducing: TestU01.

TestU01

I ran the BigCrush test battery from TestU01 on all four algorithms (see the reports).

A very surprising result!

First of all, given PCG’s reputation I’d expect it to pass. Is it possible the Elm implementation differs enough from the official one that it screws something up? Another experiment using the official PCG algorithm and constants would be needed.

Secondly, JKISS32 passes with flying colors. At least that gives us a clear favorite when we’ll next look at performance.

I don’t really know what the failures mean in practice. The algorithms above aren’t cryptographically secure, so I don’t suppose any of them is safe from predicting new values from previous ones etc., but maybe there could be some bias that could realistically affect users in web app / game / simulation scenarios?

Anyways, being naive, let’s bias towards JKISS32 and go see the performance.

Performance benchmark

I want to measure how long it takes to generate a random number and advance the state once, and 1 million times in a typical Elm loop (that is, a tail recursive function).

For benchmarking the Elm code I have compiled (with elm make --optimize) a test program like this just to get the final JavaScript out:

import Random.CoreCurrent
import Random.CoreFixed
import Random.JKISS32
import Random.Squirrel5

coreCurrentState = Random.CoreCurrent.initialState 123456789
coreFixedState   = Random.CoreFixed.initialState   123456789
jkissState       = Random.JKISS32.initialState     123456789 234567891 345678912 456789123
squirrelState    = Random.Squirrel5.initialState   123456789

runTimes : Int -> (state -> ( Int, state )) -> state -> ()
runTimes n step state =
    if n <= 0 then
        ()

    else
        let
            ( generatedValue, newState ) =
                step state
        in
        runTimes (n - 1) step newState

runCoreCurrent_1 () = let _ = Random.CoreCurrent.step coreCurrentState in ()
runCoreFixed_1   () = let _ = Random.CoreFixed.step   coreFixedState   in ()
runJKISS32_1     () = let _ = Random.JKISS32.step     jkissState       in ()
runSquirrel5_1   () = let _ = Random.Squirrel5.step   squirrelState    in ()

runCoreCurrent_N n = runTimes n Random.CoreCurrent.step coreCurrentState
runCoreFixed_N   n = runTimes n Random.CoreFixed.step   coreFixedState
runJKISS32_N     n = runTimes n Random.JKISS32.step     jkissState
runSquirrel5_N   n = runTimes n Random.Squirrel5.step   squirrelState

main =
    let
        -- Just to prevent them from being dead-code-eliminated.
        _ = runCoreCurrent_1 ()
        _ = runCoreFixed_1   ()
        _ = runJKISS32_1     ()
        _ = runSquirrel5_1   ()
        _ = runCoreCurrent_N 1
        _ = runCoreFixed_N   1
        _ = runJKISS32_N     1
        _ = runSquirrel5_N   1
    in
    -- A necessary boilerplate to compile an Elm program
    Platform.worker
        { init = \() -> ( (), Cmd.none )
        , update = \_ _ -> ( (), Cmd.none )
        , subscriptions = \_ -> Sub.none
        }

Then I hand-picked the relevant parts into a JavaScript file and used mitata to benchmark it.

I kept the loops and function calls Elm-style instead of idiomatic JavaScript, to measure the realistic Elm behaviour one can reach.

Here are the results. I’m striking through the current elm/random code because while it’s fastest, I’d prefer correctness over performance.

Box plots reported by Mitata:

1x

                   ┌                                            ┐
                   ╷┬
       coreCurrent ├│
                   ╵┴
                                           ╷┌─┬                 ╷
coreFixedUserspace                         ├┤ │─────────────────┤
                                           ╵└─┴                 ╵
                   ┌┬
   coreFixedNative ││
                   └┴
                          ╷┬            ╷
           jkiss32        ├│────────────┤
                          ╵┴            ╵
                                     ┌┬             ╷
         squirrel5                   ││─────────────┤
                                     └┴             ╵
                   └                                            ┘
                   1.83 ns            6.21 ns            10.59 ns

1000000x

                   ┌                                            ┐
                   ╷┬╷
       coreCurrent ├│┤
                   ╵┴╵
                                                   ┌┬╷
coreFixedUserspace                                 ││┤
                                                   └┴╵
                                         ┌┬┐╷
   coreFixedNative                       ││├┤
                                         └┴┘╵
                                                              ┌┬╷
           jkiss32                                            ││┤
                                                              └┴╵
                         ╷┬╷
         squirrel5       ├│┤
                         ╵┴╵
                   └                                            ┘
                   10.43 ms           16.30 ms           22.18 ms

The current elm/random algorithm is really fast compared to all the others. I think it also must have to do with lack of function calls (which in Elm-produced JavaScript sometimes end up doing extra logic around arity due to partial application) in its implementation.

If I had to pick from the rest and JKISS32’s BigCrush test results weren’t enough reason to pick it (or at least disqualify the rest and go search for another function), Squirrel5 seems to have great performance across multiple runs although it’s not the fastest one in the “1x” test.

Note these numbers will surely be wildly different from their C counterparts: we’re operating in a GC’d interpreted language with a JIT…

Final results

We learned there’s a bug in the elm/random PRNG implementation, causing it to fail the Dieharder randomness test suite.

We learned that even fixing this bug doesn’t make it pass the TestU01 randomness test suite, something we’d expect from the PCG family of PRNGs. Further exploration of how the Elm implementation differs from the official one is needed.

We learned about using hash functions as PRNGs; it can be surprisingly fast (likely because virtually all the work is hidden in the generation, incrementing an integer to advance the state is negligible).

This whole journey is probably not enough to conclusively say there is a clear winner, a function that (in context of JavaScript) provides the best performance while passing all the randomness tests. Maybe there is one out there, but we didn’t find it today.

Addendum: JavaScript bitwise tricks

Here are JavaScript snippets for converting numbers to unsigned and signed 32bit numbers with its bitwise operators, which you might be familiar with from asm.js:

const toU32 = (n) => n >>> 0;
const toI32 = (n) => n | 0;

// 0xFFFFFFFF     == 4294967295
// 0xFFFFFFFF | 0 == -1
// -1 >>> 0       == 4294967295

// 0x100000000       == 4294967296
// 0x100000000 | 0   == 0
// 0x100000000 >>> 0 == 0

Leaving the house (and the country) for a week or two during the holiday season is a great time to get out of my stereotypical ways of passing free time (entirely too much YouTube, Lobste.rs, HackerNews and BlueSky) and try something else.

For my recent vacation I have packed some grid paper to make a bitmap font, and two books: the first one was Nachové pustiny: a Czech post-apocalyptic novel to get some inspiration for my “Fallout but in Czech Republic” MMO game, and the other was Thinking in Systems: a book recommended at work (and bought with my work education budget) which was collecting dust in my bookshelf for a good few months now.

I’m happy to announce I managed to get through all three of these goals: I’ve created a bitmap font (though I still have kerning and accents to go through), devoured the post-apo novel (it was okay), and got through the systems book!

Thinking in Systems introduces a framework and a visual language of sources and sinks, stocks and flows, feedback loops and systems that (more often than not) emerge bottom-up from them.

It all roughly corresponds to mathematical models and differential equations, though the book doesn’t go into detail of those and only mentions the actual formulas for its examples in an appendix.

Delays are weird

There was one really cool chapter that IMHO is the highlight of the whole book. It concerns delays.

The running example (see image above) is a car dealership manager shepherding a stock of cars on their parking lot, aiming for it to always be 10x the amount of cars sold. When the customer demand rises, she starts ordering more cars to cover the gap.

Delay-less system

In an ideal world there are no delays: she immediately sees an increased demand and the discrepancy between the current stock and the ideal one, she immediately sends an order to bring more cars in, and the cars immediatelly arrive.

Also, in this example the time granularity is days, so imagine that at the end of the day she sees 30 cars got sold, sends an order for 30 cars and they arrive the next morning.

Let’s first see the constants in our model that won’t be affected by the delays:

The customer demand starts at 20 cars each day, then ramps up to 22 cars each day, with a spike of 70 cars on one specific day.

Sales are min(customer demand, inventory), which in all examples below will equal customer demand, as we have enough cars ready, but you can imagine getting out of stock if demand gets high enough fast enough.

Our manager calculates the desired inventory as sales * 10. Might be simplistic but hey, it’s an example.

You could also imagine us later averaging over sales from past N days and basing the desired inventory off of that, and thus introducing yet another delay into the system, but I’ve omitted it from this blogpost as it doesn’t touch what I want to illustrate.

So, how does the delay-less model behave?

BTW, I have written a Monte Carlo simulator myself in Elm while reading the book—it lists the pseudocode formulas for the examples in this blogpost—but a spreadsheet would suffice, and there are other tools to deal with these differential equation models. Heck, there’s a free graphical webapp built on top of a JS library showing off the same example I do in one of its examples. I guess the book is influential.

This model has no delays, but it has an issue with overreacting to the random spikes in customer demand by buying too many cars which then take forever to sell, and more importantly it’s unrealistic: in the real world everything has a bit of a delay. The orders take time to process, the cars take time to arrive at the dealership lot, and so on. We’ll call that the delivery delay.

That seems like a bad delay, but delays don’t need to always be bad: consider that the manager might want to not overreact to those random spikes. She had ordered 550 cars because of a spike, when she normally orders only around 20 a day! Instead she might want to get to the desired inventory slowly over time by ordering only half of the discrepancy, or a third, etc. If on the next day things get back to normal, we’ll be able to ride the wave much more smoothly without overreacting. Let’s call this divisor the response delay.

System with delays

Let’s run the model with these two delays and see:

• delivery delay: 5 days (from me sending the order to the cars arriving on the lot)
• response delay divisor: 2 (if I see a discrepancy of 30 cars, I’ll only order 15 today.)

What? What just happened? We thought we’re doing everything right, the response delay was a good thing!

Well it is. But the combination of the two delays made our system oscillate! It never stabilizes even if the customer demand remains constant afterwards.

The manager is caught in a vile cycle of ordering too many cars, then ordering more and more the following days before the first order arrives. Once orders start arriving, she now has too many cars and ends up not ordering any more while waiting for the inventory to get back to the ideal levels. But then with more car sales the inventory dips below the ideal again and she starts the cycle again.

I’d be interested in learning what, mathematically, makes these oscillations inevitable. Some more math-heavy book on these models and differential equations will probably explain that. For now let’s just take the oscillations caused by delays for a fact.

Shorter delays: surely the fix?

Now you might think that since delays got us into this mess, we should minimize them as much as possible. Shorten the feedback loop and all. But remember, we introduced the response delay to be more resilient towards random spikes. Anyways, let’s try and see what happens:

• delivery delay: 5 days (we can’t speed up this one)
• response delay divisor: 1 (be as fast as we can: buy the exact amount we’re missing at end of day)

Hm. As you can see, trying to be faster made things worse: our inventory of cars now oscillates much more: cycles of shooting up from 132 to 518, while we’d like to be around 220. Not to mention having to have 1160 cars in our lot at once after the spike! This is even worse than the no-delays scenario! Is there any hope?

Longer delays: Take it easy, Dude…

Just to see what will happen: let’s simulate a more patient manager: one that spreads out the restocking over a longer period of time. Let’s make our response delay divisor larger and try 6. When we see a discrepancy of 30 cars at the end of the day, let’s just order 5 instead of 10 or 15 or 30.

• delivery delay: 5 days (still out of our control)
• response delay divisor: 6 (slower response! longer delay!)

Wow! The oscillations died out and stabilized!

Conclusion

This was pretty counterintuitive to me when I read it. Delays intuitively seem like something you want to minimize. But here, shortening a delay made things worse and making it longer made things more predictable and less wasteful.

In the later parts of the book Donella Meadows mentions short feedback loops; there’s no clear cut rule that you could apply blindly. Make a model of your system, try different parameters, see how it behaves.

Many managers and leaders take the lever that the researchers provide, and crank it full speed, wrong direction. You might think you know which way is the correct one, but maybe, just maybe, get insight into how your system would behave in both directions and act on data instead of on intuition.

P.S.

Feel free to play around with the toy simulator for this example. The code is at Github.

Obviously one is good enough but slow (or is it), and the other one is fast and fun but not sustainable.

Is there a compromise in the middle that’s an improvement over not using LLMs at all, and work-safe? (By work-safe I mean, you understand the code you submitted in relation to the rest of the codebase, and the code meets some quality bar.)

(Note: the specific numbers are made up and the points don’t matter.)

0.00 (all manual, no LLM delegation)

This is pretty self-explanatory. It’s how we all programmed before LLMs were a thing. But this starting point is not the subject of this post - we want to search the space for an usable point or range on it. So let’s go straight to the other side.

1.00 (vibe coding, PM instructing a dev)

While it’s fun to experience this extreme – “write me an app that does XYZ” – and eventually see your side project drive into a ditch, I don’t believe it’s viable for anything long term (with current state-of-the-art models: Opus 4.5 as of the time of writing. Yes I know, Opus 4.6 released today; I haven’t tried it yet.).

You don’t know the codebase, tests are non-existent or bad or there’s not enough of them… You’re just hoping adding a new feature or fixing a bug didn’t break something else, and mostly rely on your own manual user-testing for quality control.

I think it’s not controversial to mark this one as unsafe for work.

0.70 (dev instructing a junior dev)

So, in a not quite binary-search style we go to the middle. (I’d mark this one as 0.50 but then my crude Figma chart labels would overlap later. Let’s not speak of it again.)

We’ve now dropped from high-level prompts to a lower level. We specify technical details to the agent, outline algorithms or high level approaches, ask for specific tests or write them ourselves; we skim the LLM code and read tests carefully. We still write almost no code ourselves.

I think this is borderline usable for side projects with no real-world importance and 0-1 users (you). The test suite does a lot, and quadruples the project’s TTAOAR (Time To Abandonment Or A Rewrite).

This might be controversial, but I’ll say it’s not enough for serious work. (See also the Others? section for extra nuance.)

0.20 (prompt-less Tab autocomplete)

Instead of exploring the space from the right, let’s explore it from the safe side for a moment.

I’d say that next to the 0.00 point, there’s the “Github Copilot” mode of writing code. The “magic Tab” autocomplete in the editor.

You still are technically writing all the code, and the LLM is trying to finish your sentences. When it guesses right, you press Tab. There’s never any prompting from your side.

I think this is a pretty safe use of LLMs, and to me, it feels like a speed up when writing the boring boilerplate parts of the code. Whether it actually is a speed up, I don’t (want to) know.

Examples of these boilerplate autocompletes I can think of: Elm JSON decoders and encoders, or listing all branches of a case..of expression. Brain-dead code. A substantial part of this are code patterns that a good LSP server would give you too, deterministically, without any LLM guessing.

But, somebody needs to write that LSP. And when it doesn’t exist or it isn’t good enough, it’s pretty nice that LLMs can substitute this for you. And they autocomplete other scenarios too, for example function bodies, so I think there’s still some value there, even with a good LSP present.

On the topic of completing function bodies, I think there’s a risk here of just accepting whatever the LLM suggests, and then reading through it and tweaking it or accepting it. That’s slightly sketchy to me. I personally find that reviewing code is much harder than writing it, and it’s hard to switch between these two contexts on the fly. Maybe this is why (my) reviews of LLM code are so half-hearted.

So, it seems to me that this way of working with LLMs is safe, as long as you always have the code to write in your mind and only let the LLM autocomplete if that code is roughly identical to what you wanted to write. Consider not pressing Tab if you didn’t have a plan for what to write, or how to implement something, to stay in the authoring mode instead of switching to a review mode.

Cool, it looks like we have an improvement! I think we’re ready to find another point in between the usable and the unusable part of the spectrum.

0.40 (localized Cmd+K prompts in editor)

There’s another mode of using LLMs, which I like to call the Cmd+K mode (based on the keyboard shortcut Cursor uses for it).

You’re in your editor (not in the agent chat UI!), select a part of the code, press Cmd+K and say “please refactor this function to use an exhaustive switch statement”.

The LLM makes a suggestion, while never overstepping the boundaries of your selection. Sometimes that means it adds redundant import statements to the top of the selection—I suspect it doesn’t have the whole file / codebase in its context so it doesn’t know what’s outside the selection? Would be nice if it did, it feels inferior in intelligence to the agent chat otherwise—but other than that it’s pretty sweet.

The localized aspect of it means that you’re the one moving the cursor and driving this code generation, which I suspect is good for your mental model and keeping a sane API between the functions and modules. It also means you have less code to review, and have the context necessary to understand the change or addition, because you’ve just asked for it. So from the perspective of having an up-to-date theory of the code in your mind, this is great (although not as good as writing the code yourself).

There’s a way to perverse this, by selecting the whole file and prompting “implement X”. That gives you an inferior, lobotomized version of an agent, while making it harder for yourself to review the code, because now suddenly the changes are all across the file instead of localized to a function. You need to build context during review for what the functions inside are doing now. So I wouldn’t recommend that.

I’d say the localized version is right around the limit of what is safe for work or serious code. (Still unsure whether it’s inside the safe interval or outside it.)

I value having an up-to-date mental model of the code in my head and being able to recollect and roughly explain what each high-level part of it does. (I can do this for some code I haven’t touched in years; I can’t do this for agent-written code I have willed into existence last week.)

With this localized Cmd+K generation, you haven’t written some parts of the code anymore, so you might be hazy about how exactly does a step work. The same way you learn(ed) more at school by writing than by reading, you get a better picture of the code by writing the code yourself (and struggling to figure out how to do all the tiny details) than by reviewing the LLM’s output.

Others?

When I set out to write this post, I didn’t quite expect to draw the line at “agent mode bad”… But here we are!

Maybe there are ways to use agents that I’m not familiar with that somehow manage to make you hold all the important details about the codebase in your head, the same way writing the code manually would. I don’t know of them.

You might be screaming at me: you fail using LLMs because you’re not using XYZ! I know there are ways to use agents with extra structure and product-managerial practices on top: Agent Skills, superpowers, spec-kit, Ralph loops and surely more pop up every day.

I think they live somewhere between the rightmost two points on my made-up spectrum:

I don’t have enough experience with whether these methodologies make the code robust enough or not, whether they keep you-the-developer in the loop enough to keep your mental model of the codebase fleshed out (I really think this is a big deal), instead of it becoming a black box over time and degrading your interaction with the agent and the codebase back towards the 1.00 YOLO vibe coding extreme.

I’m pretty vanilla when it comes to agents; I’ve tried spec-kit on a compiler project once but it seems to have hit a wall when given a hard enough sub-task.

In my case, the model couldn’t keep conversions between a language AST and emitted VM bytecode operations straight, emitting sequences that didn’t do what they should, eg. retrieving an array element at an index.

It might be interesting to hear from people who finished non-trivial projects with these structures on top of vanilla LLM agents. I hope they do exist; whenever I read Lobste.rs or Hacker News, there’s a new OSS utility claiming to be ready for use, but then you spend 2 minutes looking at its output and it’s obviously wrong (sorry for the dig).

We seem to have lost the sense of responsibility for quality of the code we publish the moment we started delegating it to LLMs.

Also not mentioned, but possibly worth discussing: using LLMs to learn about codebases, debug code, find possible optimizations and refactors, etc. Each would warrant a separate discussion, outside of “whether/how to use agents to actually write code.”

Conclusion

The “agent” part of the spectrum doesn’t seem to overlap with the interval where the developer ends up knowing what the codebase does, and where the codebase is healthy.

As of this moment, with my limited experience, I’m really skeptical there’s a good compromise that both allows using agents and ends up with safe-for-work, maintainable code and a developer that, over time, maintains intimate familiarity with the codebase.

So maybe don’t use agents at work?

<homer_hides_into_a_bush.gif>

There’s also a possibility I’m just uniquely unwilling to review agent code at a PR scale and bad at forming a mental model by reading alone, and others have a different experience with agents.

In my frontend developer pre-LLM days, collaborating with other team members on a shared codebase, the parts I wrote were always much clearer to me than the parts others wrote that I just reviewed. And I swear I made effort to understand the changes made by others. It always took having to touch the code to truly internalize it.

Maybe the secret for responsible LLM use is in intentionally taking the time to touch the code between agent sessions? Some healthy balance of the two?

Maybe even if one person on the team uses LLMs irresponsibly, but another writes code manually and cleans things up or vetoes certain patterns in code reviews, the codebase survives? I don’t know.

But I won’t be all-in on agent use by default anytime soon. If quality of the code is important and I’m to be responsible for it (note that for some side projects, prototypes or experiments it’s fine not to!), I will be in my editor, touching most code myself, only sometimes accepting suggestions from the LLM or asking it to write small functions. I will (try to) resist delegating most of the actual coding work to an agent.

Tab and Cmd+K or die.

P.S.: I can’t wait to read this in a year and cringe at my views.

P.P.S.: Isn’t it ironic to write this whole thing and have the link to a previous post be about vibe coding a programming language interpreter ⬇️. I’d say that one goes in the “this is a throwaway experiment and quality doesn’t matter” category, so I believe I’m still consistent with myself here!

I knew I’m addicted to the combination of algebraic data types (tagged unions) and exhaustive pattern matching, but what got me this time was immutability, lexical scope and the basic human right of being allowed to return arrays from functions.

Part 1 of the Advent of Code problem was easy enough, but for part 2 (basically a shortest path search with a twist, to not spoil too much), I found myself unable to switch from my usual functional BFS approach to something mutable, and ended up trying to implement my functional approach in AWK.

It got hairy very fast: I needed to implement:

• hashing of strings and 2D arrays (by piping to md5sum)
• a global set array of seen states
• a way to serialize and deserialize a 2D array to/from a string
• and a few associative arrays for retrieving this serialized array by its hash.

I was very lost by the time I had all this; I spent hours just solving what felt like accidental complexity; things that I’d take for granted in more modern languages.

Now, I know nobody said AWK is modern, or functional, or that it promises any convenience for anything other than one-liners and basic scripts that fit under a handful of lines. I don’t want to sound like I expect AWK to do any of this; I knew I was stretching the tool when going in. But I couldn’t shake the feeling that there’s a beautiful AWK-like language within reach, an iteration on the AWK design (the pattern-action way of thinking is beautiful) that also gives us a few of the things programming language designers have learnt over the 48 years since AWK was born.

Dreaming of functional AWK

Stopping my attempts to solve the AoC puzzle in pure AWK, I wondered: what am I missing here?

What if AWK had first-class arrays?

BEGIN {
  # array literals
  normal   = [1, 2, 3]
  nested   = [[1,2], [3,4]]
  assoc    = ["foo" => "bar", "baz" => "quux"]
  multidim = [(1,"abc") => 999]

  five = range(1,5)
  analyze(five)
  print five  # --> still [1, 2, 3, 4, 5]! was passed by value
}

function range(a,b) {
  r = []
  for (i = a; i <= b; i++) {
    r[length(r)] = i
  }
  return r  # arrays can be returned!
}

function analyze(arr) {
  arr[0] = 100
  print arr[0]  # --> 100, only within this function
}

What if AWK had first-class functions and lambdas?

BEGIN {
  # construct anonymous functions
  double = (x) => { x * 2 }
  add = (a, b) => { c = a + b; return c }

  # functions can be passed as values
  apply = (func, value) => { func(value) }

  print apply(double,add(1,3))  # --> 8
  print apply(inc,5)  # --> 6
}

function inc(a) { return a + 1 }

What if AWK had lexical scope instead of dynamic scope?

# No need for this hack anymore ↓     ↓
#function foo(a, b         ,local1, local2) {
function foo(a, b) {
  local1 = a + b
  local2 = a - b
  return local1 + local2
}

BEGIN {
  c = foo(1,2)
  print(local1)  # --> 0, the local1 from foo() didn't leak!
}

What if AWK had explicit globals, and everything else was local by default?

BEGIN { global count }
END {
  foo()
  print count  # --> 1
  print mylocal # --> 0, didn't leak
}
function foo() { count++; mylocal++ }

(This one, admittedly, might make programs a bit more verbose. I’m willing to pay that cost.)

What if AWK had pipelines? (OK, now I’m reaching for syntax sugar…)

BEGIN {
  result = [1, 2, 3, 4, 5] 
      |> filter((x) => { x % 2 == 0 })
      |> map((x) => { x * x })
      |> reduce((acc, x) => { acc + x }, 0)

  print "Result:", result
}

Making it happen

TL;DR: Janiczek/fawk on GitHub

Now for the crazy, LLM-related part of the post. I didn’t want to spend days implementing AWK from scratch or tweaking somebody else’s implementation. So I tried to use Cursor Agent for a larger task than I usually do (I tend to ask for very small targeted edits), and asked Sonnet 4.5 for a README with code examples, and then a full implementation in Python.

And it did it.

Note: I also asked for implementations in C, Haskell and Rust at the same time, not knowing if any of the four would succeed, and they all seem to have produced code that at least compiles/runs. I haven’t tried to test them or even run them though. The PRs are here.

I was very impressed—I still am! I expected the LLM to stumble and flail around and ultimately get nothing done, but it did what I asked it for (gave me an interpreter that could run those specific examples), and over the course of a few chat sessions, I guided it towards implementing more and more of “the rest of AWK”, together with an excessive amount of end-to-end tests.

Take a look at those tests!

The only time I could see it struggle was when I asked it to implement arbitrary precision floating point operations without using an external library like mpmath. It attempted to use Taylor series, but couldn’t get it right for at least a few minutes. I chickened out and told it to uv add mpmath and simplify the interpreter code. In a moment it was done.

Other things that I thought it would choke on, like print being both a statement (with > and >> redirection support) and an expression, or multi-dimensional arrays, or multi-line records, these were all implemented correctly. Updating the test suite to also check for backwards compatibility with GAWK - not an issue. Lexical scoping and tricky closure environment behaviour - handled that just fine.

What now?

As the cool kids say, I have to update my priors. The frontier of what the LLMs can do has moved since the last time I tried to vibe-code something. I didn’t expect to have a working interpreter the same day I dreamt of a new programming language. It now seems possible.

The downside of vibe coding the whole interpreter is that I have zero knowledge of the code. I only interacted with the agent by telling it to implement a thing and write tests for it, and I only really reviewed the tests. I reckon this would be an issue in the future when I want to manually make some change in the actual code, because I have no familiarity with it.

This also opened new questions for me wrt. my other projects where I’ve previously run out of steam, eg. trying to implement a Hindley-Milner type system for my dream forever-WIP programming language Cara. It seems I can now just ask the LLM to do it, and it will? But then, I don’t want to fall into the trap where I am no longer able to work on the codebase myself. I want to be familiar with and able to tinker on the code. I’d need to spend my time reviewing and reading code instead of writing everything myself. Perhaps that’s OK.

Performance of FAWK might be an issue as well, though right now it’s a non-goal, given my intended use case is throwaway scripts for Advent of Code, nothing user-facing. And who knows, based on what I’ve seen, maybe I can instruct it to rewrite it in Rust and have a decent chance of success?

For now, I’ll go dogfood my shiny new vibe-coded black box of a programming language on the Advent of Code problem (and as many of the 2025 puzzles as I can), and see what rough edges I can find. I expect them to be equal parts “not implemented yet” and “unexpected interactions of new PL features with the old ones”.

If you’re willing to jump through some Python project dependency hoops, you can try to use FAWK too at your own risk, at Janiczek/fawk on GitHub.

EDIT 2025-11-10: Hacker News folks pointed out it might not be clear to everybody what BEAM is: it’s the virtual machine for languages like Erlang, Elixir and Gleam. See Wikipedia.

I was always fascinated with BEAM, how it allowed easy spawning of processes that didn’t share state, allowed for sending and selectively receiving messages, and linking to each other thus enabling creation of supervision trees.

It’s an interesting set of primitives that interact in a nice way, and are in my view responsible for much of the appeal of BEAM languages. I wanted to see how much it takes to support these primitives, and I set out to write my own toy MVP implementation of BEAM.

As a disclaimer, I haven’t read The BEAM Book yet, and how I do things might differ substantially from how the real BEAM does things. This is an exploration from first principles based on how I perceive BEAM from the outside, and doesn’t aim for truthfulness to the reference implementation, real world usefulness nor performance.

The below examples are written in Elm, but if you can express it in Elm, you can express it in anything (it’s purely functional so there’s no mutation, it’s single threaded and has no concurrency primitives, etc.).

AST representation

I will only be making the scheduler and its main loop, not a full-blown language or VM. This allows me to only keep a few hardcoded examples around and skip writing a parser, CLI and a bunch more parts that a real compiler would have.

In the interest of skipping as much work as possible, I’ll be using continuation passing style (CPS) for the example programs instead of the usual “list of statements” style:

-- ☑️ YES: continuations
type Program
    = End
    | Work Int K
    | Spawn Program KPid
    | Send Pid String K
    | Receive String K
    | Crash
    | Link Pid K

type alias K =
    () -> Program

type alias KPid =
    Pid -> Program

-- ❌ NO: list of statements
type Stmt
    = Let String Expr
    | Work Int
    | Spawn Program
    | Send Pid String
    | Receive String Program
    | Crash
    | Link Pid

type alias Program =
    List Stmt

This means I don’t have to care about environments, bindings, scopes, return values, expressions and so on, as this will be handled by the continuation arguments in the host language:

ex5 : Program
ex5 =
    Spawn ex5Child       <| \childPid ->
    Send childPid "Ping" <| \() ->
    End

ex5Child =
    Work 10 <| \() ->
    End

In case you’re having issues reading the <| operator, you can imagine a pair of parentheses instead:

ex5 : Program
ex5 =
    Spawn ex5Child       (\childPid ->
    Send childPid "Ping" (\() ->
    End
    ))

ex5Child =
    Work 10 (\() ->
    End
    )

Instruction: End

The continuations in all the non-terminal instructions force us to provide at least one terminal, otherwise we couldn’t write a valid Program value.

Let’s then start by implement one of the terminals, End. It’s a no-op, but it will allow me to show off the structure of the scheduler.

type Program =
    End

ex1 : Program
ex1 =
    End

type alias Scheduler =
    { program : Program }

init : Program -> Scheduler
init program =
    { program = program }

step : Scheduler -> Scheduler
step sch =
    case sch.program of
        End -> sch

Try it online, or try the visualizer below:

Everything will revolve around this Scheduler type and its step function. Now let’s expand our capabilities.

Instruction: Work

Instead of wasting time implementing instructions for actual work (mathematic operators, function calls, etc.), let’s encompass this all with a dummy Work instruction, holding the amount of work (in units that will start making sense soon) and a continuation with what to do after the work:

type Program
    = End
    -- Added:
    | Work Int K

type alias K =
    () -> Program

ex2 : Program
ex2 =
    Work 5 <| \() ->
    End

The example holds a program that will “work” for 5 units of work then end.

We need to add this new instruction to our step function:

step : Scheduler -> Scheduler
step sch =
    case sch.program of
        End -> sch
        -- Added:
        Work n k -> { sch | program = k () }

For now we’ll just ignore how much work it’s supposed to be, and continue with the rest of the program (result of calling the continuation: k ()).

Try it online, or try the visualizer below:

Instruction: Spawn

Let’s do something interesting! We’ll add a way to spawn other processes, thus making our programs concurrent.

type Program =
    -- ...
    | Spawn Program KPid

type alias KPid =
    Pid -> Program

type alias Pid =
    Int

ex3 : Program
ex3 =
    Work 5         <| \() ->
    Spawn ex3Child <| \childPid ->
    Work 5         <| \() ->
    End

ex3Child : Program
ex3Child =
    Work 10 <| \() ->
    Work 10 <| \() ->
    End

Whenever we spawn another process, we’ll receive its PID in the continuation, which will be useful later for messaging and other tasks.

This marks a big change in our Scheduler: suddenly we have to track multiple processes instead of just one!

type alias Scheduler =
    { processes : Dict Pid Proc
    , nextUnusedPid : Pid
    , readyQueue : Queue Pid
    }

type alias Proc =
    { program : Program }

init : Program -> Scheduler
init program =
    { processes = Dict.empty
    , nextUnusedPid = 0
    , readyQueue = Queue.empty
    }
        |> spawn program
        |> Tuple.first -- discard the spawned PID

spawn : Program -> Scheduler -> ( Scheduler, Pid )
spawn program sch =
    let pid = sch.nextUnusedPid in
    ( { sch
        | processes =
            sch.processes
                |> Dict.insert pid (initProc program)
        , nextUnusedPid = pid + 1
      }
        |> enqueue pid
    , pid
    )

initProc : Program -> Proc
initProc program =
    { program = program }

enqueue : Pid -> Scheduler -> Scheduler
enqueue pid sch =
    { sch
        | readyQueue =
            if List.member pid (Queue.toList sch.readyQueue)
            then sch.readyQueue
            else sch.readyQueue |> Queue.enqueue pid
    }

We hold the processes in a Dict collection now, there’s a bit of bookkeeping for incrementing PIDs, and a new concept: the “ready queue.”

This queue will tell our scheduler which process to run next. This means our step function needs to change considerably: previously it was able to just pick the (only) program with sch.program, but now it needs to pick a PID from the queue, then find it in the dictionary, then run it:

step : Scheduler -> Scheduler
step sch =
    case Queue.dequeue sch.readyQueue of
        Nothing -> sch
        Just ( pid, restOfQueue ) ->
            let newSch = { sch | readyQueue = restOfQueue } in
            case Dict.get pid newSch.processes of
                Nothing   -> newSch
                Just proc -> newSch |> stepInner pid proc

stepInner : Pid -> Proc -> Scheduler -> Scheduler
stepInner pid proc sch =
    case proc.program of
        End -> sch

        Work n k ->
            sch
                |> updateProc pid (setProgram (k ()))
                |> enqueue pid

updateProc : Pid -> (Proc -> Proc) -> Scheduler -> Scheduler
updateProc pid fn sch =
    { sch | processes =
        sch.processes
            |> Dict.update pid (Maybe.map fn)
    }

setProgram : Program -> Proc -> Proc
setProgram newProgram proc =
    { proc | program = newProgram }

The specifics of stepInner had to change as well: we can’t set the single sch.program anymore, we need to update an entry for a PID in the processes dictionary.

Let’s not forget about the new instruction:

stepInner pid proc sch =
    -- ...
    Spawn childProgram kpid ->
        let ( schWithChild, childPid ) =
                sch |> spawn childProgram
        in schWithChild
               |> updateProc pid (setProgram (kpid childPid))
               |> enqueue pid

We reuse the spawn function from before. It gives us the child’s PID, which we can use to access the rest of the parent program via the continuation: kpid childPid.

We need to remember to enqueue the parent again (the program given by the continuation hasn’t run yet); the child has already been enqueued in the spawn function.

Try it online, or try the visualizer below.

Our scheduler now takes 7 steps to finish the whole program, which corresponds to the 7 instructions in our initial program.

Reduction budget

Can you see any potential issues with our current Scheduler?

The concurrency we have implemented is cooperative: a started process won’t be stopped by the scheduler in the middle. Consider this program:

ex4 : Program
ex4 =
    Work 5         <| \() ->
    Spawn ex4Child <| \childPid ->
    Work 5         <| \() ->
    End

ex4Child : Program
ex4Child =
    Work 999 <| \() -> -- !!!
    Work 10  <| \() ->
    End

This only differs from example 3 by the amount of work the child is doing. The parent can’t finish its tiny bit of work after the spawn until the child finishes its 999 units of work.

The way BEAM solves this is with a reduction budget: it creates an illusion of preemptive scheduling on top of the cooperative one by inserting yield points after every function call, decrementing its reduction budget in each, and once the budget reaches 0, the scheduler will pause the process and start another one from the queue.

This works surprisingly well: in BEAM languages, you iterate through lists via recursion → there’s a lot of function calls → a lot of yield points.

We’ll do something similar in our toy implementation: introduce a reduction budget, and make the Work instruction only do as much “work” as the budget allows.

reductionBudget : Int
reductionBudget =
    7 -- BEAM sets this to 4000.

step : Scheduler -> Scheduler
step sch =
    -- ...
    sch |> stepInner pid proc {- added: -} reductionBudget

stepInner : Pid -> Proc -> Int -> Scheduler -> Scheduler
stepInner pid proc budget sch =
    if budget <= 0
    then sch
         |> setProc pid proc
         |> (if shouldEnqueue proc
             then enqueue pid
             else identity)
    else -- ...

shouldEnqueue : Proc -> Bool
shouldEnqueue proc =
    case proc.program of
        -- Optimization: if we ended up on `End`,
        -- we don't need to run again.
        End -> False
        Work _ _ -> True
        Spawn _ _ -> True

setProc : Pid -> Proc -> Scheduler -> Scheduler
setProc pid newProc sch =
    sch
        |> updateProc pid (\_ -> newProc)

Above we’re dealing with the case where the process ran out of the budget. The scheduler will remember where it ended, re-enqueue it if there’s more work to do (if we’re not at the End instruction), and stop the current step.

Let’s flesh out the rest of stepInner:

stepInner pid proc budget sch =
    -- ...
    else
    let
        stop : Scheduler -> Scheduler
        stop sch_ =
            sch_ |> stepInner pid program 0

        continue : Program -> Int -> Scheduler -> Scheduler
        continue newProgram newBudget sch_ =
            sch_ |> stepInner pid newProgram newBudget
    in
    -- ...

Here I’m making helpers for working with the budget. stop sets the budget to 0 and recurses, so that we go straight to the if budget <= 0 then ... code path.

continue instead sets the budget to some arbitrary number we provided. Usually we’ll decrement the current budget by 1, but in case of Work we’ll jump in larger increments.

Let’s use them:

stepInner pid proc budget sch =
    -- ...
    in
    case program of
        End -> sch |> stop

        Spawn childProgram kpid ->
            let ( schWithChild, childPid ) =
                    sch |> spawn childProgram
            in schWithChild
                   |> continue (kpid childPid) (budget - 1)

        Work n k ->
            if n <= 0
            then sch |> enqueue pid
                     |> continue (k ()) budget
            else let workDone = min n budget
                     workRemaining = n - workDone
                     budgetRemaining = budget - workDone
                 in sch |> continue (Work workRemaining k)
                                    budgetRemaining

The Work instruction now works completely differently: instead of doing all the work at once (going straight for k ()), it now finally cares about the amount of work present.

We will only continue with k () if there’s no more work to be done (n <= 0).

Otherwise we calculate how much work can be done, and update the remaining work and budget accordingly.

Try it online, or try the visualizer below.

Take a look at the first few steps after the child spawns:

Thus, even though the child has a lot of work to be done, the scheduler preempts and only lets it do the work in chunks of 7, and the parent process gets a chance to do some of its work as well.

Instruction: Send

Spawning processes without letting them communicate is not very useful. It might help move computations off the main thread, but obviously we’ll want some inter-process communication eventually.

Let’s add a way to send messages to processes. (Receiving them will come later.)

type Program
    = -- ...
    | Send Pid String K

shouldEnqueue : Proc -> Bool
shouldEnqueue proc =
    -- ...
    Send _ _ _ -> True

ex5 : Program
ex5 =
    Spawn ex5Child       <| \childPid ->
    Send childPid "Ping" <| \() ->
    End

ex5Child : Program
ex5Child =
    Work 10 <| \() ->
    End

To implement this Send instruction, we’ll need to introduce the concept of mailboxes:

type alias Proc =
    { program : Program
    -- Added:
    , mailbox : Queue String
    }

Sending a message will be done by putting the message into this mailbox. We can do that because we have access to the whole scheduler, we are not limited to just the current process’ resources:

stepInner pid proc budget sch =
    -- ...
    Send destinationPid message k ->
        sch
            |> send destinationPid message
            |> continue (k ()) (budget - 1)

send : Pid -> String -> Scheduler -> Scheduler
send destinationPid message sch =
    sch
        |> updateProc destinationPid (enqueueMessage message)
        |> enqueue destinationPid

enqueueMessage : String -> Proc -> Proc
enqueueMessage message proc =
    { proc | mailbox = proc.mailbox |> Queue.enqueue message }

When we send a message to a process, we also enqueue it to make sure it has a chance to process it. This will become important later, when processes go to sleep (ie. don’t enqueue) after not finding any interesting message for their selective receive. We’ll get there!

Try it online, or try the visualizer below.

The child has the message in its mailbox, but can’t react to it. Let’s fix that!

Instruction: Receive

type Program
    = -- ...
    | Receive String K

This is a substantial simplification from what the real BEAM needs to support: Erlang receive statement allows for multiple branches, pattern matching inside the branches, timeouts when there’s no interesting message present for a certain amount of time, and so on.

We will instead only support a single string message with no destructuring. The process won’t continue until this specific string is found in the mailbox.

ex6 : Program
ex6 =
    Spawn ex6Child       <| \childPid ->
    Send childPid "Ping" <| \() ->
    End

ex6Child : Program
ex6Child =
    Receive "Ping" <| \() -> 
    Work 10        <| \() ->
    End

We can make an interesting optimization in the shouldEnqueue function:

shouldEnqueue proc =
    -- ...
    -- Optimization: we don't need to `Receive`
    -- if there's no interesting message.
    Receive wantedMsg _ ->
        Queue.toList proc.mailbox
            |> List.any (\msg -> msg == wantedMsg)

This means we won’t reenqueue a process at the end of stepInner if it’s waiting for a message that’s not present in its mailbox. There’s no reason for the process to try again until a new message is received, so the process will instead go to sleep and wait to be woken up later in the send function.

There’s a wall of code coming up, brace yourselves! When interpreting the Receive instruction, we’ll go through messages until we find the wanted one. If we find it, remove it from the mailbox and use the continuation, otherwise go to sleep with the mailbox intact.

stepInner pid proc budget sch =
    -- ...
    continue_ : Proc -> Int -> Scheduler -> Scheduler
    continue_ newProc newBudget sch_ =
        sch_ |> stepInner pid newProc newBudget
    -- ...
    Receive wantedMsg k ->
        let processMessages : List String -> Queue String -> Scheduler
            processMessages unmatchedStartRev restOfMailbox =
                case Queue.dequeue restOfMailbox of
                    -- NO MORE MSGS TO CHECK
                    Nothing ->
                        sch |> stop

                    Just ( msg, restOfMailboxWithoutThis ) ->
                        if msg == wantedMsg then
                            -- FOUND IT
                            let newMailbox =
                                  Queue.fromList
                                      (List.reverse unmatchedStartRev
                                          ++ Queue.toList restOfMailboxWithoutThis)
                            in
                                sch |> continue_
                                           (proc
                                               |> setMailbox newMailbox
                                               |> setProgram (k ())
                                           )
                                           (budget - 1)

                        else 
                            -- TRY NEXT
                            processMessages
                                 (msg :: unmatchedStartRev)
                                 restOfMailboxWithoutThis
        in
        processMessages [] proc.mailbox

setMailbox : Queue String -> Proc -> Proc
setMailbox newMailbox proc =
    { proc | mailbox = newMailbox }

This code is not very elegant due to plucking a message from the middle of a queue, but it does what I described in the previous paragraph.

Try it online, or try the visualizer below.

You can see things have lined up nicely: process 1 has "Ping" in its mailbox and also is about to try and Receive "Ping". In the next step the message is gone and the process is doing Work. Success!

Instruction: Crash, Link

For the last piece of the puzzle, let’s look at the feature that gives rise to supervision trees: linking processes together.

Linking is bidirectional; the scheduler will send a system message to the other side of the link whenever a linked process exits (in our example, crashes). The receiving side can choose to react to this exit signal: respawn the other process? Crash ourselves? Log it somewhere and do cleanup?

Note: BEAM also has monitors. These are one-directional, and I’ll skip them in this blogpost.

type Program
    = -- ...
    | Crash
    | Link Pid K

type alias Proc =
    { -- ...
    , links : Set Pid
    }

initProc program =
    { -- ...
    , links = Set.empty
    }

ex7 : Program
ex7 =
    Spawn ex7Child <| \childPid ->
    Link childPid  <| \() ->
    Receive ("CRASH: " ++ String.fromInt childPid) <| \() ->
    End

ex7Child : Program
ex7Child =
    Crash

shouldEnqueue proc =
    -- ...
    Crash    -> True
    Link _ _ -> True

Why Crash -> True? The Crash instruction is a terminal, but it has work to do inside (sending the system messages), so we’ll enqueue it if it hasn’t run yet. (We’ll replace Crash with End after doing that work.)

stepInner pid proc budget sch =
    -- ...
    Link linkedPid k ->
        sch
            |> link pid linkedPid
            |> continue (k ()) (budget - 1)

link : Pid -> Pid -> Scheduler -> Scheduler
link pid1 pid2 sch =
    sch
        |> updateProc pid1 (addLink pid2)
        |> updateProc pid2 (addLink pid1)

addLink : Pid -> Proc -> Proc
addLink pid proc =
    { proc | links = proc.links |> Set.insert pid }

And Crash is where we actually use proc.links:

stepInner pid proc budget sch =
    -- ...
    stop_ : Proc -> Scheduler -> Scheduler
    stop_ newProc sch_ =
        sch_ |> stepInner pid newProc 0
    -- ...
    Crash ->
        sch
            |> propagateCrashToLinks pid
            |> stop_ (proc |> setProgram End)

propagateCrashToLinks : Pid -> Scheduler -> Scheduler
propagateCrashToLinks pid sch =
    case Dict.get pid sch.processes of
        Nothing   -> sch
        Just proc ->
            proc.links
                |> Set.foldl
                    (\linkedPid accSch ->
                        accSch
                          |> send linkedPid
                                  ("CRASH: " ++ String.fromInt pid)
                    )
                    sch

In a real-world interpreter, we’d distinguish between user messages and system messages by using an ADT, but for this toy implementation, the above will be enough.

Try it online, or try the visualizer below:

It works in the Ellie link above, but not in the visualizer. Why? Their reduction budget is different. The Ellie demo manages to run Spawn and Link without anything else running in between, but the visualizer has reduction budget of 1, and so the child Crashes before the parent manages to Link to it.

This can be fixed by making the instruction pair a single atomic instruction, and BEAM does this with the spawn_link function. You can try it online or click the Fix the problem button in the demo above.

Conclusion

And that’s all! We have implemented:

• spawning child processes
• sending and selectively receiving messages
• an illusion of preemptive scheduling on top of cooperative scheduling using a reduction budget
• linking between processes, essentially adding hooks for when a related process stops for some reason

These primitives combine together in nice ways, giving rise to BEAM’s reputation. I think they’re pretty neat, and I hope this toy implementation demystified them a little bit for you!

I do love PBT-testing data container libraries against the “spec” when given the opportunity, and since I created myself a small tool called elm-bench for easier benchmarking, I couldn’t resist and decided to find all the queue packages currently available on package.elm-lang.org and put them under the microscope. Let’s thoroughly test and benchmark them!

The rest of this blogpost shows the results of my testing and benchmarking, and I will attempt to categorize the packages and recommend the best ones.

Spoiler alert: I did find a bug, though not in the new library that started the whole effort!

Packages

Here’s what we’ll be testing:

• avh4/elm-fifo @ 1.0.4
• dwayne/elm-queue @ 1.0.0
• folkertdev/elm-deque @ 3.0.1
• kudzu-forest/elm-constant-time-queue @ 1.4.0
• owanturist/elm-queue @ 2.0.0
• robinheghan/elm-deque @ 1.0.0
• turboMaCk/queue @ 1.2.0

Note I have excluded francescortiz/elm-queue from the comparison because it deals with rate limiting, keyed values etc. and is not as general-purpose as the others. One could create a generic queue out of it but it would have severe overhead (2+ orders of magnitude).

On the other hand, I am including deques (double-ended queues) in the comparison.

Expected API: what is a Queue?

Queues are relatively simple: they’re a container holding 0+ items, and you can efficiently push (enqueue) an item on one side and pop (dequeue) an item on the other side (first in, first out).

Let’s expect the some variation on the following API from all of these packages:

type Queue a
empty : Queue a
isEmpty : Queue a -> Bool
singleton : a -> Queue a
fromList : List a -> Queue a
toList : Queue a -> List a
enqueue : a -> Queue a -> Queue a
dequeue : Queue a -> Maybe (a, Queue a)
length : Queue a -> Int

For length, if the package doesn’t give us an “official” way, we have two options on how to implement it: via toList and via repeated calls to dequeue (or perhaps fold, if provided). The performance difference could swing both ways, so let’s create both and measure instead!

API differences

All of the packages indeed allow us to express the above API.

Here is a comparison of which functions are provided out of the box:

Other exposed functions:

• dwayne/elm-queue (1)
  • peek
• folkertdev/elm-deque (11+5)
  • append, member, first, takeFront, map, map2, andMap, filter, foldl, partition, isEqualTo
  • deque-specific: pushBack, popFront, last, takeBack, foldr
• kudzu-forest/elm-constant-time-queue (6)
  • head, map, fold, isEqual, fromListLIFO, toListFIFO
• owanturist/elm-queue (34)
  • repeat, range, head, tail, take, drop, partition, unzip, any, all, member, maximum, minimum, sum, product, map, indexedMap, foldl, foldr, filter, filterMap, reverse, append, concat, concatMap, intersperse, map2, map3, map4, map5, sort, sortBy, sortWith, equals
• robinheghan/elm-deque (15+4)
  • initialize, repeat, range, append, left, right, dropLeft, dropRight, member, first, map, filter, filterMap, foldl, partition
  • deque-specific: pushBack, popFront, last, foldr
• turboMaCk/queue (5)
  • front, dropFront, map, filter, updateFront

Equality gotcha

Note that using the built-in Elm == equality operator on queues is unsafe for ALL of these packages, as some values can have multiple internal representations. The canonical example is Chris Okasaki’s queue design with two lists, one for the rear and one for front. You could imagine two queues for singleton 1: Q [1] [] and Q [] [1], and so on.

When working with Queue packages you need to use their provided equality predicates, or use toList to find out if two queues contain the same values in the same order.

Expected invariants

Here are the properties I believe should hold for any queue. Properties having ∀ (“for all”) qualifiers can be checked using property-based tests, properties not having them can be checked using unit tests.

Note that many of these will overlap; I’ve just found it easiest to find properties by looking at pairs of functions.

The == operator below is to represent the correct way to compare two queues for equality (see note above).

Here’s the types of the variables introduced in the for-alls:

x : a
xs : List a
q : Queue a -- created via fromList

The invariants we will be checking:

• empty / isEmpty
  • isEmpty empty == True
• empty / singleton / enqueue
  • ∀x: enqueue x empty == singleton x
• empty / singleton / dequeue
  • ∀x: dequeue (singleton x) == Just (x, empty)
• empty / fromList
  • empty == fromList []
• empty / toList
  • toList empty == []
• empty / dequeue
  • dequeue empty == Nothing
• empty / length
  • length empty == 0
• isEmpty / singleton
  • ∀x: isEmpty (singleton x) == False
• isEmpty / fromList
  • ∀xs: isEmpty (fromList xs) == List.isEmpty xs
• isEmpty / toList
  • ∀q: isEmpty q == List.isEmpty (toList x)
• isEmpty / length
  • ∀q: isEmpty q == (length q == 0)
• singleton / fromList
  • ∀x: singleton x == fromList [x]
• singleton / toList
  • ∀x: toList (singleton x) == [x]
• singleton / length
  • ∀x: length (singleton x) == 1
• fromList / toList
  • ∀xs: toList (fromList (xs)) == xs
• fromList / enqueue
  • ∀x,xs: enqueue x (fromList xs) == fromList (xs ++ [x])
• fromList / length
  • ∀xs: length (fromList xs) == List.length xs
• toList / enqueue
  • ∀x,q: toList (enqueue x q) == toList q ++ [x]
• toList / length
  • ∀q: length q == List.length (toList q)
• enqueue / length
  • ∀x,q: length (enqueue x q) == 1 + length q
• length
  • ∀q: lengthViaToList q == lengthOriginal q (where applicable)
  • ∀q: lengthViaDequeue q == lengthOriginal q (where applicable)
  • ∀q: lengthViaToList q == lengthViaDequeue q

Invariant differences / bugs found

All tested packages behaved identically and as-expected, with the exception of owanturist/elm-queue.

This library behaves differently wrt. fromList and toList: compared to other libraries, they act as if they reversed the list in question:

dequeue (fromList [1,2,3])
-- owanturist/elm-queue:
Just (3, queueWithout3)
-- others:
Just (1, queueWithout1)

toList (enqueue 999 (singleton 1))
-- owanturist/elm-queue:
[999,1]
-- others:
[1,999]

Taken together, the two bugs cancel out (ie. the roundabout test “fromList / toList” doesn’t catch them), which makes them sneakier in retrospect.

This was submitted to the package repository as issue #5.

Performance

I’m using elm-bench to write these benchmarks. It’s a tool I wrote to reduce boilerplate when using the de-facto Elm benchmarking library, elm-explorations/benchmark.

Benchmarks were ran on a Macbook Pro (16-inch, Nov 2024) with the Apple M4 Pro CPU and 48 GB RAM; Node v22.16.0 and Elm 0.19.1.

My setup is the following:

.
├── v01_avh4
│   ├── elm.json
│   ├── src
│   │   └── CommonApi.elm
│   └── tests
│       └── QueueInvariants.elm
├── v02_dwayne
│   ├── elm.json
│   ├── src
│   │   └── CommonApi.elm
│   └── tests
│       └── QueueInvariants.elm
├── v03_folkertdev
│   ├── elm.json
│   ├── src
│   │   └── CommonApi.elm
│   └── tests
│       └── QueueInvariants.elm
├── v04_kudzu-forest
│   ├── elm.json
│   ├── src
│   │   └── CommonApi.elm
│   └── tests
│       └── QueueInvariants.elm
├── v05_owanturist
│   ├── elm.json
│   ├── src
│   │   └── CommonApi.elm
│   └── tests
│       └── QueueInvariants.elm
├── v06_robinheghan
│   ├── elm.json
│   ├── src
│   │   └── CommonApi.elm
│   └── tests
│       └── QueueInvariants.elm
└── v07_turboMaCk
    ├── elm.json
    ├── src
    │   └── CommonApi.elm
    └── tests
        └── QueueInvariants.elm

Each of the CommonApi.elm files contains an implementation of the, well, common API.

The implementations (and tests) for each tested package can be found in the accompanying repository: Janiczek/elm-queues-shootout.

I then run the benchmarks via elm-bench in the “version” mode: this allows me to have a separate project for each library. I can’t use them all in the same Elm project because of module name collisions: many of the packages export a module named Queue, and there can only be one.

alias bench_queues="elm-bench --json -v v01_avh4 -v v02_dwayne -v v03_folkertdev -v v04_kudzu-forest -v v05_owanturist -v v06_robinheghan -v v07_turboMaCk"

Example usage:

bench_queues CommonApi.dequeue "(CommonApi.fromList (List.range 1 5))"
bench_queues CommonApi.enqueue 1 CommonApi.empty

elm-bench ensures the arguments to the function are precomputed (by putting them in their own top-level declarations, which are then computed during program initialization and before the benchmark starts). This means we aren’t measuring the runtime of computing the arguments.

The --json flag gives output in a JSON form, from which the measurement can be plucked via jq ".[].nsPerRun". All measurements are in nanoseconds per run (that is, per the measured function call).

Finally, “small queue/list” means List.range 1 5 and “Large queue/list” means List.range 1 500.

Measurements

I need to preface this with: this is all on a nanosecond scale. Don’t be wooed by the absolute differences here - does your webapp really care about 0.2ns vs 3ns? Which operations will it do often? The O(1) vs O(N) time complexities will probably be more instructive, though again you have to think about the realistic sizes of your queues. Are they going to hold more than a few hundred items?

The table with the measurements is on Github, my blog CSS is simply not up to such a gargantuan task and I can’t be bothered to tweak it right now. CSV is more usable than a HTML table anyways!

Some charts (as always, click to zoom):

Based on the limited amount of datapoints (lengths of the input list or queue), I believe we can jot down these time complexities:

It’s fascinating to see how at such small timescales, every little function call, if expression and pattern match matters. There is a very visible bimodality: the empty case behaves very differently from the two measured non-empty cases, taking a different path through the code. Sometimes surprisingly for the worse!

When a library implements length, it’s usually way better (in most cases, O(1)) than anything you can implement yourself from toList or dequeue (where you’re guaranteed O(N)).

And yet again, it’s hard to say how much will a hypothetical webapp feel any of this. We’re on the scale of nanoseconds, basically almost none of this matters unless you’re doing this in a hot loop or on huge datasets!

length / fromList tradeoff

There is an inevitable tradeoff between O(1) length + O(N) fromList and O(N) length + O(1) fromList, as the native Elm lists don’t hold length metadata and thus have O(N) length themselves.

This means that to hold the precomputed number of elements in the queue implementation (O(1) length), you need to count the elements during insertion: O(N) fromList.

If you instead want to just hold the list the user gave you, without walking it (possibly O(1) fromList), you’ll have to walk it in length to count the elements (O(N) length).

You have to count the elements somewhere: on the way in or on the way out.

Categorization

It seems that there are two categories you can choose from:

• Deques with somewhat rich List-like API, O(1) length and O(N) fromList
  • Both folkertdev/elm-deque and robinheghan/elm-deque fit the bill.
  • Robin’s library seems faster at fromList and slower at toList.
  • Robin also mentions possible performance differences in his README, though I haven’t tested and measured these.
• Queues based on Chris Okasaki’s “two lists” design, with O(1) fromList and O(N) length
  • avh4/elm-fifo, dwayne/elm-queue and turboMaCk/queue belong here.
  • There are almost no differences. Dwayne’s library seems a bit slower on enqueue and dequeue than the other two. One might prefer turboMaCk’s library to avh4’s due to slightly richer API.
  • A future (version of a) library could differentiate itself here by implementing a rich List-like API.

owanturist/elm-queue does have the richest API out of all the tested packages, would otherwise belong with the other three Okasaki queues and would be my recommended choice (if you don’t need a deque), but contains the buggy/surprising fromList and toList behaviour.

I’m not completely sure where to put kudzu-forest/elm-constant-time-queue. The constant-time promise for enqueue doesn’t seem to be there and the code needed for worst-time guarantees is making this library slower overall, though note that my code benchmarked one specific way of constructing a queue, and perhaps queues that are used in a more mixed way (enqueue, dequeue, enqueue again) would be more stable compared to other packages?

Summary

We found a bug in one of the libraries!

If you need a deque, choose between folkertdev/elm-deque and robinheghan/elm-deque based on the needed API or whether you’ll use fromList or toList more often.

If you just need a queue, I recommend turboMaCk/queue solely based on having slightly richer API to avh4/elm-fifo.

And if you’re one of the authors of the above libraries, adding more helper functions would help and would make you my immediate favorite :)

TL;DR: turn off automatic updates then flash an older firmware via LPR over the network.

TL;DR 2: Buy a Brother.

I’m writing this post to help the next poor sod who wants to install an unofficial cartridge into their HP printer.

It started giving me the “Non-HP Chip Detected” error and refused to print anything from that point on.

All the usual tips that said I should turn the printer off, pull the plug, wait a minute and then turn it on, or that I should press the power-off button for 30s or more – none of that worked. The error was still there.

I tried futzing around with “Cartridge Policy” in the printer web interface (which explicitly said it would allow non-HP cartridges), and that didn’t work either.

In the end I opted to flashing an older firmware. I turned off automatic updates via the printer touchscreen UI, and started searching for the older firmware binaries.

Thanks to a Reddit post I was able to find an official HP download URL (instead of some shady 3rd party website):

http://ftp.hp.com/pub/softlib/software13/fw-recover/M478-M479_MA/HP_Color_LaserJet_Pro_MFP_M478-M479_series_FW_002_1916A.ful2

Then I tried putting that on an USB stick and flashing the printer that way. Didn’t work, the back USB port resulted in the printer trying to format the flash drive, and the front USB port tried to find something to print on the drive.

Thanks to another Reddit post I was able to find an alternative way to flash the printer: through the LPR protocol.

I needed to install the lpr utility via “Turn Windows Features on or off” then run the following in the commandline:

lpr -S 192.168.8.109 -P 192.168.8.109 HP_Color_LaserJet_Pro_MFP_M478-M479_series_FW_002_1916A.ful2

After the command finished, it looked like nothing’s happening but then the printer restarted and started installing the firmware. After that all was done, the error was gone and my printer started printing again!

Recently I was discussing a TigerBeetle article on swarm testing with Jeroen Engels on the Elm Slack, and at one point, reading the paragraph:

For example, one weakness of our test above is that we chose to pop and push with equal probability. As a result, our queue is very short on average. We never exercise large queues!

He asked:

How does one detect which situations are or aren’t covered in practice by property-based tests? Like, when would you say “the distribution we have doesn’t cover this case”?

How do you indeed! You could use Fuzz.examples to visually check whether the generated values make sense to you:

-- inside Elm REPL
> import Fuzz
> Fuzz.examples 10 (Fuzz.intRange 0 10)
[4,6,3,6,9,9,9,3,3,6]
    : List Int

but did you just get unlucky and saw no 0 and 10, or do they never get generated?

To build the motivation a little bit, let’s try and see the issue from the TigerBeetle blogpost. Assume we have a Queue implementation (the details don’t matter):

type Queue a
empty  : Queue a
push   : a -> Queue a -> Queue a
pop    : Queue a -> (Maybe a, Queue a)
length : Queue a -> Int

Now let’s try to test it!

type QueueOp
    = Push Int
    | Pop

queueOpFuzzer : Fuzzer QueueOp
queueOpFuzzer =
    Fuzz.oneOf
        [ Fuzz.map Push Fuzz.int
        , Fuzz.constant Pop
        ]

applyOp : QueueOp -> Queue Int -> Queue Int
applyOp op queue =
    case op of
        Push n ->
            Queue.push n queue

        Pop -> 
            Queue.pop queue
                |> Tuple.second

queueFuzzer : Fuzzer (Queue Int)
queueFuzzer =
    Fuzz.list queueOpFuzzer
        -- would generate [ Push 10, Pop, Pop, Push 5 ] etc.
        |> Fuzz.map (\ops -> List.foldl applyOp Queue.empty ops)
        -- instead generates a queue with the ops applied

The queueFuzzer makes a sort of random walk through the ops to arrive at a random Queue.

Now if we were worried we’re not testing very interesting cases, we could debug-print their lengths and look at the logs real hard and make a gut decision about whether it’s fine, but doesn’t that feel a bit icky?

Well, you can instead get this lovely table:

Distribution report:
====================
  length 2-5:     37%  (370x)  ███████████░░░░░░░░░░░░░░░░░░░
  length 0:     29.6%  (296x)  █████████░░░░░░░░░░░░░░░░░░░░░
  length 1:     22.8%  (228x)  ███████░░░░░░░░░░░░░░░░░░░░░░░
  length 6-10:   9.7%   (97x)  ███░░░░░░░░░░░░░░░░░░░░░░░░░░░
  length 11+:    0.9%    (9x)  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

when you use Test.reportDistribution in your test:

Test.reportDistribution
    [ ( "length 0",    \q -> length q == 0 )
    , ( "length 1",    \q -> length q == 1 )
    , ( "length 2-5",  \q -> length q >= 2 && length q <= 5 )
    , ( "length 6-10", \q -> length q >= 6 && length q <= 10 )
    , ( "length 11+",  \q -> length q >= 11 )
    ]

What’s more, you can also make the tests fail when something’s not tested enough:

✗ Queue example 2
    Distribution of label "length 11+" was insufficient:
      expected:  10.000%
      got:       1.400%.

    (Generated 1000 values.)

using Test.expectDistribution:

Test.expectDistribution
    [ ( Test.Distribution.atLeast 10, "length 0",    \q -> length q == 0 )
    , ( Test.Distribution.atLeast 10, "length 1",    \q -> length q == 1 )
    , ( Test.Distribution.atLeast 10, "length 2-5",  \q -> length q >= 2 && length q <= 5 )
    , ( Test.Distribution.atLeast 10, "length 6-10", \q -> length q >= 6 && length q <= 10 )
    , ( Test.Distribution.atLeast 10, "length 11+",  \q -> length q >= 11 )
    ]

With all of the secrets out, let me now properly introduce you to Test.Distribution. It’s a relatively new addition to the Elm test library API (added in v2.0.0, has been 3 years already, wow) which lets you measure or alternatively enforce how often each interesting case needs to happen.

This was ported over from Haskell QuickCheck (of course), where this is done with functions like label and checkCoverage, and there’s an amazing talk “Building on developers’ intuitions to create effective property-based tests” by John Hughes (of course) that explains the idea further.

Before I get to the actual Test.Distribution stuff, let me also say that in addition to the Fuzz.examples mentioned earlier there’s also Fuzz.labelExamples which you can use in the REPL to see an example of each labelled case (if it occurs):

Fuzz.labelExamples 100
    [ ( "Lower boundary (1)",    \n -> n == 1 )
    , ( "Upper boundary (20)",   \n -> n == 20 )
    , ( "In the middle (2..19)", \n -> n > 1 && n < 20 )
    , ( "Outside boundaries??",  \n -> n < 1 || n > 20 )
    ]
    (Fuzz.intRange 1 20)
-->
[ ( [ "Lower boundary (1)" ],    Just 1 )
, ( [ "Upper boundary (20)" ],   Just 20 )
, ( [ "In the middle (2..19)" ], Just 3 )
, ( [ "Outside boundaries??" ],  Nothing )
]

As you can see, each case consists of a label and a predicate. These can overlap:

Fuzz.labelExamples 100
    [ ( "fizz", \n -> (n |> modBy 3) == 0 )
    , ( "buzz", \n -> (n |> modBy 5) == 0 )
    ]
    (Fuzz.intRange 1 20)
-->
[ ( [ "fizz" ],       Just 3 )
, ( [ "buzz" ],       Just 10 )
, ( [ "fizz, buzz" ], Just 15 )
]

You can use these classifiers in your test suites: Test.fuzzWith has a distribution field where you can choose between:

• noDistribution: the default
• reportDistribution: shows a histogram of which label happens how often
• expectDistribution: fails the test if a labelled case doesn’t happen as specified:
  • atLeast: N% of the time or more
  • zero: never
  • moreThanZero: at least once

Let’s see some more examples. Test.reportDistribution used in the following way:

Test.fuzzWith
    { runs = 10000
    , distribution =
        Test.reportDistribution
            [ ( "fizz", \n -> (n |> modBy 3) == 0 )
            , ( "buzz", \n -> (n |> modBy 5) == 0 )
            , ( "even", \n -> (n |> modBy 2) == 0 )
            , ( "odd",  \n -> (n |> modBy 2) == 1 )
            ]
    }
    (Fuzz.intRange 1 20)
    "Fizz buzz even odd"
    (\n -> Expect.pass)

will show the following histogram:

Distribution report:
====================
  even:             50.2%  (5017x)  ███████████████░░░░░░░░░░░░░░░
  odd:              49.8%  (4983x)  ███████████████░░░░░░░░░░░░░░░
  fizz:             30.1%  (3011x)  █████████░░░░░░░░░░░░░░░░░░░░░
  buzz:             19.2%  (1924x)  ██████░░░░░░░░░░░░░░░░░░░░░░░░

Combinations (included in the above base counts):
  fizz, even:       15.2%  (1524x)  █████░░░░░░░░░░░░░░░░░░░░░░░░░
  fizz, odd:        10.1%  (1013x)  ███░░░░░░░░░░░░░░░░░░░░░░░░░░░
  buzz, even:        9.5%   (949x)  ███░░░░░░░░░░░░░░░░░░░░░░░░░░░
  buzz, odd:           5%   (501x)  ██░░░░░░░░░░░░░░░░░░░░░░░░░░░░
  fizz, buzz, odd:   4.7%   (474x)  █░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

As you would expect, of the 20 numbers in the range 1..20,

• there are 10 even and 10 odd ones
  • the labels even and odd should happen with probability 10/20 (50% of the time), though the real counts will vary slightly due to randomness
• there are 6 multiples of 3
  • the label fizz should happen with probability 6/20 (30% of the time)
• there are 4 multiples of 5
  • the label buzz should happen with probability 4/20 (20% of the time)

Note the combinations are disjoint in a sense: the hits for fizz, buzz, odd aren’t counted in fizz, odd and that’s why fizz, odd only shows around 10% probability instead of the expected 15%: fizz, buzz, odd has stolen the missing 5% from it as a more specific combination of labels.

Distributions are more useful when you enforce them instead of just reporting them. Use Test.expectDistribution:

Test.fuzzWith
    { runs = 100
    , distribution =
        Test.expectDistribution
            [ ( Test.Distribution.atLeast 4,    "low",        \n -> n == 1 )
            , ( Test.Distribution.atLeast 4,    "high",       \n -> n == 20 )
            , ( Test.Distribution.atLeast 80,   "in between", \n -> n > 1 && n < 20 )
            , ( Test.Distribution.zero,         "outside",    \n -> n < 1 || n > 20 )
            , ( Test.Distribution.moreThanZero, "one",        \n -> n == 1 )
            ]
    }
    (Fuzz.intRange 1 20)
    "Int range boundaries - mandatory"
    (\n -> Expect.pass)

In the test above, we expect the uniform fuzzer of numbers 1..20 to produce the number 1 at least 4% of the time. If the real probability was 2%, the test would fail on grounds of distribution, even though the actual test function always passes.

In reality the number 1 will happen 5% of the time (1/20; Fuzz.intRange is uniform), but it’s not the best idea to enforce the exact probability that will happen, because the library tries to run the fuzzer until it’s statistically sure (1 false positive in 10⁹ runs) that the distribution is reached.

This means that instead of the default 100 fuzzed values it might end up generating thousands or millions of values to make sure. So being a bit off the real probability helps keep the test suite fast.

Test.expectDistribution won’t show the table and will generally be silent, but it will complain loudly and fail the test if the wanted distribution isn’t reached (even if the actual test function passes), like in the following example where I’ve bumped the expected probability of generating the number 1 to 10%:

✗ Int range boundaries - mandatory
    Distribution of label "low" was insufficient:
      expected:  10.000%
      got:       5.405%.

    (Generated 2146 values.)

You can see it generated 2146 values to be sure of the result, instead of the specified 100.

That about covers it! This post mostly wants to show that this can be done in the Elm PBT testing world; if you want to dive deeper I heartily recommend the mentioned YouTube talk by John Hughes.

TL;DR: with Test.Distribution you can measure and enforce how often do your tests generate categories of values of your choosing.

OK, now that you’ll stay, let’s start from the beginning…

I’m a Type 1 diabetic. This means my pancreas doesn’t produce insulin (which allows cells to use blood glucose for energy) and I have to provide it externally.

This is a finnicky process, because you need to balance your glucose in the right “zone” - not too high (hyperglycemia, >10 mmol/l, is a long-term danger to your body) and not too low (hypoglycemia, <4 mmol/l, is a short-term danger to your body). If it’s too high, you need to inject insulin, and if it’s too low, you need to eat some sugars.

A commonly used metaphor for this is flying a plane. There are games illustrating the process as well: click blue button, bird flies down, click orange button, bird flies up. Too high bad, too low bad, just right good.

The issues with manually managing this process you’ve inherited from your douchebag pancreas are manifold:

• the insulin doesn’t act immediately, there’s around 20min delay (depending on the brand) before your blood glucose goes down
• the food doesn’t act immediately, there’s around 20min delay (depending on the food!) before your blood glucose goes up
  • simple sugars (eg. fruit) are faster (and stop acting faster as well)
  • complex sugars (rice / potatoes / …) are slower. You usually want your blood glucose as constant and flat as possible. The worst thing you can do is to go from hypo to hyper to hypo to hyper in huge amplitude swings.
  • fats also somehow affect the digestion of sugars. I can’t be bothered to remember how, I just ignore them honestly.
• injecting insulin ~15min before you start eating would do wonders for neutralizing the BG spike, the issue is, nobody does it, because what if you then get a smaller serving at the restaurant or it gets delayed? What if you get called somewhere urgently and can’t finish your meal? People usually inject right before the meal / after the meal as a result.
• there’s no generic formula (that I know of) for estimating how much will a gram of sugar increase your blood glucose, nor how much will an unit of insulin decrease your blood glucose. It’s all vibes.
• mathematical models do exist but you need to find your body’s parameters - I’ll get to it below!
• the body has its own emergency reserves of glucose, which it can sometimes decide to use (though beware, this system turns off when you’re drunk), so maybe the Snickers bar you just ate to save your life wasn’t actually needed anymore, and you end up with a hyper
• you’re not quite yourself during a hypo (you get slower, dumber, I’ve heard of people getting stuck in thought loops in front of an open fridge), and so even though you intellectually know you just ate enough to get back into the correct levels eventually, your brain is screaming at you “EAT! YOU’RE DYING! I AM LOW ON SUGAR NOW!!“ and in my case this leads to overcompensating quite knowingly and willingly. Yeah one more yoghurt can’t hurt. Well…
• insulin doesn’t work when eaten, you need to inject yourself with it (though nowadays we do it under skin, not into veins, I sure am glad I’m not living 50 years ago) or inhale it. Since injections aren’t the most pleasant thing in the world, the dosage is usually limited to 4x a day (to counteract the three main meals + a long-acting different type of insulin once a day), even though you’d be more stable if you injected more often, with smaller doses.
  • (no experience with inhalations here, so I’ll skip this)
  • (insulin pumps do exist, I’ll mention those briefly in a moment… maybe)
• measuring your blood glucose level is painful if you are using test strips and need to prick your fingers to provide a blood drop, so measuring your sugar is usually limited to 4-6x a day – again, even though it would be better to have more data points.
  • this is less of a problem nowadays with Continuous Glucose Monitoring systems like Freestyle Libre, which you install into your arm once every 14 days and get a measurement every minute through Bluetooth to your phone
• things like physical effort, illness, stress, heck, even seasons of the year do all affect how your body behaves and reacts to sugar / insulin
• there’s this damn thing called dawn phenomenon that some diabetics, me included, experience: in the morning your sugar will just start going up and up. If you wanted to sleep in on the weekend, well tough luck, you’re now in the 15 mmol/l range.

I hope this incomplete list gives you an idea of how wonky the process of trying to make your blood glucose stay in the right levels is.

My treatment is usually: keep the Freestyle Libre app on my phone open as much as possible and when I see my BG’s getting high, I inject a small amount of insulin. How much? No idea. IT’S ALL VIBES.

But sometimes the app is yelling at you: “you’re at 15 mmol/l for an hour now, idiot!” and you just don’t (want to) pay attention. Alert fatigue is a real thing.

I have some recommended insulin dosages that we’ve settled on with my diabetologist, whom I visit every three months. So my regimen can look like:

• Breakfast: inject 18 units, eat 24g of sugars
• Lunch: inject 22 units, eat 60g of sugars
• Dinner: inject 21 units, eat 60g of sugars
• Before sleep: inject 32 units of long-acting insulin

And then I see my diabetologist, she looks at the 7d / 14d / 30d averages and says “maybe you can try fixing the 15:00 hypers you’re getting quite regularly, by injecting more insulin before lunch. You should also lose weight, when you started coming here you had 80kg, now you’re a centurion. Like seriously, WTF. OK cool bye, see you in 3 months!”

Lovely.

If you can’t tell, the thing that irks me the most about the whole thing is: Ï̷̛̛̮̏̀̊͠T̵̨̡̏͝’̵̧͍̐̂̑̈́͐̐͜S̸͉̖͒̈̀̕͝ ̴̢̺̤̜͎͚̙́Ạ̷͕̱͖͙̉̊L̴̼̞̺̤̞̬̟̅̈́L̷̠̔̏̐̃̚ ̴̞̊͛͝V̸͇͚̱͑̄̈̌̊Ḯ̴̧̧͚̰̞̈́͝B̸̡̬̪͊̌͂̓̐E̵͙̼̰̞̹͇̎̽̈́̓Ş̷̱͍͖̼͍̯̉̾͊̂̾͝. I’d seriously appreciate it if my diabetologist used a model, or a simulation of some kind, got my body’s parameters there somehow, and found the improvements to my schedule that way. Maybe she has some expert knowledge in her head but from my perspective it’s all guessworks. Err, I mean v̴̼̂i̴̥̇b̸̠̌e̶͙̕ś̴̲.

And this is where my programmer mind comes in.

There are people who take insulin pumps (which provide insulin in very small very frequent doses and are ~permanently injected into your body, but are otherwise dumb as a brick) and combine them with continuous glucose monitors, and make the glucose measurements inform and control the pump. This is called “closed loop” or “artificial pancreas”, and getting one officially is very hard or impossible: not FDA approved yet / you need to be part of an university study to get one / … It’s one of those things that “will be here in 5 years”, they say every year for the past 30 years.

Aside: I try not to be too butthurt about it: CGMs have just recently started being available and even fully sponsored by the Czech health insurance companies, and having a 1440-datapoints-a-day graph is a MASSIVE improvement compared to pricking your finger 4x a day and getting 4 datapoints for your blood glucose graph with nothing in between. So, the artificial pancreas is slowly coming. Unlike nuclear fusion.

The most prominent of these people hacking their devices together, in my social bubble at least, is Scott Hanselman, the Microsoft programmer guy. (Check out his talk.) He’s a T1DM as well and has been promoting the #WeAreNotWaiting initiative where people take their own pump and their own CGM and hack them together despite the healthcare companies’ pleas that it’s not approved and not safe etc. #TheyAreNotWaiting.

And that is really inspirational.

I don’t have a pump myself (and to have a chance of getting one I’d first have to find another diabetologist, which makes this into a “too much work, can’t be bothered” issue for me), so I can’t currently do quite what they are doing, but I can go with the high-level idea and #NotWait in my own way.

A few days ago I was fumbling down the stairs to our kitchen at ~3:00 in the morning to fix my hypo. (Night hypoglycemias are especially bad: what if you don’t wake up?) On the stairs I had the thought: why the hell is there no app into which I’d put my past X blood glucose values, my usual daily schedule, my weight, height, gender, age, whatever, and it would let me play with some kind of prediction (interactively!) and find good dosages / meal times / injection times? Then I would have a potentially good target to get to, and over the course of a few days I could gradually adjust my real dosage to that level and see how it behaves, and hopefully stay in the 4-10 mmol/l range much more easily.

Why doesn’t such a thing exist?

(Coincidentally I’ve also started chatting about this and other app ideas with John Pavlick. Thanks for your encouragement, John!)

So I started googling. Turns out there are many papers detailing differential equations for a model of how glucose and insulin interact, and how an artificial pancreas could get you to the correct range automatically. The issue is, I DON’T HAVE AN ARTIFICIAL PANCREAS. I have four daily injections. Give me something useful for those!

There’s not too much to pick from.

To be honest, I also don’t really know how to translate those differential equations into a simulation algorithm, even if I found a good model. I’m guessing I need to write an ODE solver like Runge-Kutta for the specific set of equations and somehow find my specific parameters for it. It’s been a while since I studied this in uni.

One of the links led me to diabetes.zcu.cz though, and in particular their SmartCGMS app (open-source too!). From the screenshots it seemed kinda relevant, or at least similar to what I had in mind for my dream app.

So I sent an email to the authors. Found one maintainer on GitHub and wrote them an email detailing my woes and the app I’d love to write, and whether they could point me to some existing software or good papers on modelling multiple-dose-injection treatment (as opposed to a pump / artificial pancreas).

What they gave me was better than I could imagine. (Thanks again, Martin!) They had a wrapper for the core SmartCGMS engine (which contains implementations of some of these models already) for the C# language. The API was quite simple:

• .Create(...) - initialize the simulation
• .Step() - step one time-unit (typically a minute) in the simulation
• .ScheduleInsulinBasalRate(double unitsPerHour) - schedule a (pump, sadly) insulin dosage
• .ScheduleInsulinBolus(double units) - schedule a short-acting insulin injection
• .ScheduleCarbohydratesIntake(double grams) - schedule food consumption
• .Terminate() - stop the simulation

And then there was the current simulation state:

• .BloodGlucose - current blood sugar, in mmol/l
• .InterstitialGlucose - glucose in your interstitial fluid - let’s skip it, not important
• .InsulinOnBoard - how much insulin is still left to be absorbed
• .CarbohydratesOnBoard - how much sugar is still left to be absorbed

As you can see, with some caveats this would let me make a simulation for my daily schedule.

So a few moments later I had something like this (in C# but here presented as Elm)

type IntakeType
  = BasalInsulin -- long-acting
  | BolusInsulin -- short-acting
  | Carbs        -- fooooooooooooood!

type alias Intake =
  { intakeType : IntakeType
  , amount : Float
  , timeMinutes : Int
  }

type alias Input =
  { basalInsulin : Intake
  , bolusInsulins : List Intake
  , carbs : List Intake
  }

type alias OutputRow =
  { minute : Float
  , bloodGlucose : Float
  , carbohydratesOnBoard : Float
  , insulinOnBoard : Float
  , interstitialGlucose : Float
  }

simulate : Input -> Int -> List OutputRow
simulate input days =
  ...

mySchedule : Input
mySchedule =
  { basalInsulin = Intake BasalInsulin (22 * 60) 32
  , bolusInsulins =
      [ Intake BolusInsulin (10 * 60) 18
      , Intake BolusInsulin (13 * 60) 22
      , Intake BolusInsulin (19 * 60) 21
      ]
  , carbs =
      [ Intake Carbs (10 * 60) 24
      , Intake Carbs (13 * 60) 60
      , Intake Carbs (19 * 60) 60
      , Intake Carbs (22 * 60) 24
      ]
  }

myPrediction : List OutputRow
myPrediction =
  simulate mySchedule 3

Never have I copied the resulting CSV into Google Sheets so fast. Tada:

Oh, wait, that’s not it. Cool piece of accidental art though! Now let me use the correct column for the X axis.

Well hot damn. The graph actually makes sense!

Granted, it’s not me in the graph but I can simulate someone now!

Let’s stash away “I need to actually simulate me, you know” as a TODO for future Martin and continue.

Next I made a Windows Forms application with an OxyPlot chart so that I don’t need to write a CSV to a file and manually copy it to Google Sheets.

Aside: what do you .NET folks use nowadays? MAUI? WPF? Xamarin Forms? It’s kinda confusing for an outsider.

This took me a while to figure out (I’m not a C# guy; honestly I’ve thought about rewriting this into F# instead the moment I had to start learning about event handlers and delegates), but I succeeded:

There’s one little issue with seeing just the first day of the simulation though, and that’s the fact that I inject my basal (long-acting) insulin at 22:00. So for the majority of the first day the glucose will just be higher because I haven’t injected the long-acting insulin yet. So let’s simulate more days just to see what happens.

Oh wow, it gets periodic by day 3! Cool!

As you can see I’ve also added the hypo- and hyperglycemic ranges so that it’s clearer where the “Goldilocks zone” lies. As it turns out, my insulin dosage is absolutely inappropriate for the person simulated by SmartCGMS right now. Hitting such severe hypoglycemia, they’d probably be dead by now (or their liver has to work overtime on dosing that emergency glucose).

OK, well then, now it’s just a small step from simulating a hardcoded

mySchedule : Input
mySchedule =
  { basalInsulin = Intake BasalInsulin (22 * 60) 32
  , bolusInsulins =
      [ Intake BolusInsulin (10 * 60) 18
      , Intake BolusInsulin (13 * 60) 22
      , Intake BolusInsulin (19 * 60) 21
      ]
  , carbs =
      [ Intake Carbs (10 * 60) 24
      , Intake Carbs (13 * 60) 60
      , Intake Carbs (19 * 60) 60
      , Intake Carbs (22 * 60) 24
      ]
  }

to automatically finding a more optimal dosage!

I’ve opened the NuGet package manager, wrote genetic and installed the most popular package: GeneticSharp. Turns out it’s really solid. It needed me to provide the usual stuff: chromosomes, crossover, selection, population size, termination criteria… and the fitness function.

The fitness function actually deserves a fuller description. It looks like this:

fitness : Input -> Float
fitness input =
  let
    output : List OutputRow
    output = simulate input 3

    longtermHypos = output |> List.takeLast (24*60) |> List.count (\row -> row.bloodGlucose < 4)
    longtermHypers = output |> List.takeLast (24*60) |> List.count (\row -> row.bloodGlucose >= 10)
    ...

    longtermHyposNormalized = longtermHypos / List.length output
    longtermHypersNormalized = longtermHypers / List.length output
    ...

    longtermHyposWeight = 15
    longtermHypersWeight = 12
    ...

    weightSum = longtermHyposWeight + longtermHypersWeight + ...
  in
  ( longtermHyposNormalized * longtermHyposWeight
  + longtermHypersNormalized * longtermHypersWeight
  + ...
  ) / weightSum

(Yes I know stuff is computed needlessly here; in the real C# code I’m doing all the intermediate result reuse you wish I did here, but I’m optimizing for understanding instead here.)

Turns out I care about many things. The following list evolved gradually but I’m only giving you the final version:

• minimize # of hypoglycemic readings in the (stabilized) last day
• minimize # of hyperglycemic readings in the last day
• as small amplitude between min and max glucose reading as possible in the last day
• minimize the sum of bolus insulin dosages
• minimize the basal insulin dosage
• minimize # of hypoglycemic readings in the stabilization phase (first 2 days)
• minimize # of hyperglycemic readings in the stabilization phase

Note that I don’t care about all of those equally. I’ve actually sorted the above list by priority: long-term hypos are the most urgent, the temporary hypers while the system settles I care about the least. I’m encoding that via the weights. Each of the normalized measurements is a number 0..1, which then gets multiplied by the weight.

I’m not quite sure whether this is the right way to encode multiple concerns into a single number, but it’s the best I could come up with without consulting math books, and it seems to work well. At least I couldn’t find a case where an input with lower (better) fitness was less preferable to me (according to my brain’s fuzzy intuition) than another input with higher (worse) fitness.

If I was able to construct all the values and sort them, I’d probably do something like

allCombinations
  |> List.sortBy (\output ->
       [ longtermHypos output
       , longtermHypers output
       , amplitude output
       , ...
       ]
     )

(that is, I can order outputs pairwise), but that’s not how the genetic programming libraries work. I believe explicitly not going through the whole space is one of their very top priorities :)

Aside: how many inputs are there? This to me looks like permutations with repetitions (order does matter), n^r , so in my case injectionPossibilities ^ injectionCount, and for my specific example schedule, 51^4 (assuming I can inject 0..50 units of insulin). That’s around 6.7 million.

So this could be bruteforceable. But I have to run the whole simulation inside the fitness function, and it takes around a second or two.

At least it’s parallelizable then! (And believe me, I’m making use of my 16 cores.)

Given it’s a pure function (basically… the results vary around the 10th decimal digit - negligible), I can memoize the fitness function for the input of four ints. The genetic algorithm ends up repeating some guesses quite a lot near the end of the simulation, so this actually saves a lot of time.

Writing a memoization function in C# was a breath of fresh air, coming from the pure FP world of Elm:

private Dictionary<List<Intake>, double> fitnessCache = new(new IntakesSameAmount());

// ...

if (fitnessCache.TryGetValue(amounts, out var cachedFitness))
    return cachedFitness;

// ...

var fitness = Fitness(newInput);
fitnessCache.Add(amounts, fitness);
return fitness;

Amazing what you can do with a bit of mutation. Yeah I’ll go return my Elm badge now.

So, with this fitness function created, I can now run the genetic algorithm. Let’s add a button and some more info to the UI, and start it off!

WELL HOT DAMN. It has optimized the insulin intakes and the patient (again, sadly not me) is now stable inside the 4-10 mmol/l range.

That’s really magical. I feel like I’ve solved diabetes. Of course it’s not as simple. There will always be unexpected things and changes you need to react to. You’ll have hypers, you’ll have hypos and it’s OK. But still. It managed to squeeze the blood glucose into the correct range.

So, what do I need to make this useful to me?

I feel like interactivity would go a long way. Being able to add injections or meals, move them up and down, left and right, and seeing the graph change based on that, would give the diabetic much better understanding than the “OK I’m gonna inject more before lunch today and see what happens two hours from now” feedback loop, or even worse, the “consult a doctor every three months” one. Did I mention I’m a big fan of short feedback loops?

Of course, it needs to simulate me instead of somebody else. I can’t use these optimized dosages because my body reacts differently. I need to consult this with the SmartCGMS folks, but the process will likely involve me downloading my historical blood glucose data off my Freestyle Libre sensor and somebody somewhere fitting the model parameters to that data. The math escapes me but it can be done.

Another issue is that the algorithm is optimized for pumps, and my basal (long-acting) insulin will need to be tracked into the model a bit differently. Right now it’s as if I was injecting 1/24-th of the dosage every hour, instead of the full dosage once a day. But once the specific insulin brand and its behaviour is tracked in the software, I will be able to call .ScheduleInsulinBasal(double units) and all should be well (and more precise), hopefully.

So, there’s a bunch of stuff yet to be done and collaborate with the SmartCGMS folks on, but I’m really excited by this, and feel empowered taking care of my diabetes better than I thought I could. WE’VE GOT THE TECHNOLOGY! Genetic algorithms and Markov Chains, baby!

What’s that? I didn’t mention Markov Chains once in the article?

Oh yeah, well, I experimented with a bunch of stuff. To end off the blogpost, here’s a stupid random walk arriving at a value iteratively. (Change each intake by a random value -2..+2, and if the fitness of that tweaked input is better, keep the change, otherwise rollback.)

I’m writing this on the plane from London to Prague, as we’re waiting for delayed takeoff due to thunderstorms over Czech Republic. (EDIT: A day later, I’m now finishing this on my couch back in Ostrava.)

I’ve spent an amazing week in the English countryside, among roughly 40(?) Elm-minded folks. Many of them are people I interact with almost daily on the Elm Slack or the Incremental Elm Discord, but for many of them this was the first time I could assign a face to a name! Same with my coworkers, John and Wolfgang. This alone made the event very special. Say what you want about online communication tools, in my mind meeting in person will always be vastly superior, at least in the friendship-forming aspect.

The venue and surrounding nature were breathtaking, the food was delicious, the accomodation was comfortable, the travel… we don’t speak about the travel.

The venue had a piano, which I appreciated very much. I like being around people without neccessarily having to hold a conversation, and this was one way to do that. Did you know there are a bunch of talented musicians in the Elm community? Mario was my partner in crime in improvising Coldplay stuff by ear, Rupert wowed me with his ability to read sheet music, Georges and Leonardo are awesome singers and I just couldn’t stop smiling when everybody joined in. James showed us his compositions, because of course he’s composing. Why am I even surprised. Leo showed off a bit of his dancing. Did you know Mark can draw like nobody’s business? Shout out also to one moment of kindness in particular: Mario stopping our round robin of who will play the piano next and instead taking the role of a mentor and teaching Janine the “anybody can play the piano: black keys are a pentatonic scale and will sound good together no matter which ones you choose” trick. Made me think about selfishness and unselfishness and actively bringing people into your circle and I appreciate Mario all that more for it.

On the music note, I also had a synthy jam with Georges, but we both kept trying to master our instruments enough to get something nice going on, and didn’t succeed on the first try. I’m sure we’ll try again one day and sound better :)

We had a bonfire on two occassions, which was very nice. I had some great conversations with Jeroen and Janine about parenthood and the varying social support for parents in different countries. (Also, I’ve been told the Japanese version of Love Is Blind is just the right amount of bizzare. Might want to check it out.)

Relatedly, I loved the banter from Ryan, the friendly Gleam+Lustre digs between Hayleigh and Jeroen (and Jeroen’s dry, on-the-edge humour all around), John’s all-around energy and witty remarks, Mario’s Evan impressions seconds before Evan comes to the room and Mario is forced to repeat and explain… The mood was electric, everybody is just so smart and friendly, Elm Camp was really something special.

The sessions! Oh the sessions. People pitched in topics they would like to talk about, learn more about, discuss, hack on, get help with, and folks flowed in and out of those sessions as their interest led them. There were some almost keynote-like sessions that basically stole attention from all the other sessions in their timeslot (Evan’s and Mario’s), but that was very well expected.

I’ve held a few sessions myself (elm-bend, elm-syntax-type-inference, stealing sourcemaps from Gren, how to combat Html.Lazy brittleness) and I’m blown away by the amount of ideas from everybody and how in some cases it suddenly became very clear which way to go, what needs to be done next, what’s the best course of action, to improve the Elm ecosystem, level-up the community and so on.

The below is a little list of exactly that - ideas and tasks I don’t want to forget, aimed at nobody in particular, but I would love to take some of these steps and perhaps others would like to as well:

• Html.Lazy brittleness
  • Make a patch to the compiled elm/virtual-dom JS that checks for Elm equality in the unhappy path where the referential-equality JS === has already failed. If JS === fails and Elm == succeeds, this is a wasteful render and we should either send an error to Sentry or wherever, or console.warn, or blink the element that got re-rendered. (See below)
  • Show the viability of Chrome Devtools’ “Paint flashing” for debugging Html.Lazy
  • Make a blogpost or a video or Elmcraft digital garden page about how to use and not use Html.Lazy. What breaks it, what is risky, what the compiled JS is for various Elm expressions and declarations, etc. Make the missing piece of docs that should have existed in elm/html. Coordinate with Jeroen, he has a draft blogpost about some of this already.
  • Make an experimental patch to elm/virtual-dom that uses the Gren approach: always use Elm == instead of the JS ===. This makes the optimization worse, but removes the brittleness and all the confusion in heads of Elm devs who outside of Html.Lazy didn’t need to think about referential equality and how the Elm compiler compiles various Elm snippets.
  • Possibly coordinate with Simon Lydell on having some of these patches in elm-watch.
• Sourcemaps
  • We’ve got a green light from Evan on possibly, after a specific compiler optimization is merged, having sourcemap generation in Elm compiler itself
  • Until then, we’ll make a standalone tool (probably, rather than extend Lamdera or elm-dev, due to having to touch the AST definitions and not making a clean diff) for generating sourcemaps for an Elm codebase. This can be done (tediously but without much brain activity needed) by applying the patch that added sourcemaps to Gren to an Elm compiler fork.
• elm-test
  • Ed Kelly had a need for keeping the equality failure rendering in elm-test while also having a custom failure message. Right now adding a custom failure message removes the equality one. Let’s have both!
• elm-bend
  • I need to continue on translating various Elm AST nodes to Bend. Right now I’m stuck on case..of expressions (the AST.Optimized node is too tailored to JS and not useful to me. I’ll need the AST.Canonical one.), but there are a bunch of lower hanging fruits for anybody interested in dipping their toes into Elm compiler development.
• elm-syntax-type-inference
  • Again, case..of is missing, alongside let expressions and then maybe some other stuff. It seems like we’re nearing the finish line!
  • But also, from some discussions with Jeroen, Mario and others it seems like maybe elm-review could get the type inference from other sources. The performance of that is unclear so for now we’ll keep chugging on with elm-syntax-type-inference.
• elm-grammar
  • Probably could be published.
  • Mark has given me a cool usecase for these dynamic parsers: developing, testing and iterating on your EBNF grammar in a web interface, regex101-style. Might be worth spinning up a quick application hosted on Github Pages or whatever.
• Elm Store pattern
  • A cool experiment would be to show how Elm apps could work with data streaming in from the server via WebSockets. (Outside Lamdera. Lamdera makes it trivial.) Right now frontends usually pretend the data they got from the backend is up-to-date even though it isn’t. What would it look like if we had auto-update of the loaded data, or notifying the user about new data available on the server (“this table has new data now, reload by clicking this button”)? What kind of backend do you need? GraphQL subscriptions? Some other WebSocket solution? Would be great to see end-to-end.
  • I could have done a better job explaining the Store pattern - better differentiate between the essentials (a record of RemoteData-like API responses, shared between pages) and the rest (Page.Foo.dataDependencies : List DataDependency etc.). Maybe revise the repo or something?

There’s probably more and I’m already forgetting stuff. Didn’t even mention all the cool stuff that others had in their talks, but I’m also not sure what is sworn by secrecy and what isn’t :) All in all I have a great feeling coming home from Elm Camp: there’s so much cool stuff happening everywhere. The future is bright, and I can’t wait to see it happen.

Thanks to the organizers for making an awesome event and getting the community together. Katja, Mario, Hayleigh, Wolfgang, James, I appreciate you! Thanks to all the Elm people who made it so enjoyable to be there. You’re awesome, everybody.

Oh and here’s to meeting in a year! Maybe in the Czech Republic this time, wink wink?