Uncertain<T>

Summary

You know what’s wrong with people? They’re too sure of themselves. Better to be wrong and own it than be right with caveats. Hard to build a personal brand out of nuance these days. People are attracted to confidence — however misplaced. But can you blame them? (People, that is) Working in software, the most annoying part of reaching Senior level is having to say “it depends” all the time. Much more fun getting to say “let’s ship it and iterate” as Staff or “that won’t scale” as a Principal. Yet, for all of our intellectual humility, why do we write vibe code like this? if currentLocation.distance(to: target) < 100 { print("You've arrived!") // But have you, really? 🤨 } GPS coordinates aren’t exact. They’re noisy. They’re approximate. They’re probabilistic. That horizontalAccuracy property tucked away in your CLLocation object is trying to tell you something important: you’re probably within that radius. Probably. A Bool, meanwhile, can be only true or false. That if statement needs to make a choice one way or another, but code like this doesn’t capture the uncertainty of the situation. If truth is light, then current programming models collapse the wavefunction too early. Picking the Right Abstraction In 2014, researchers at the University of Washington and Microsoft Research proposed a radical idea: What if uncertainty were encoded directly into the type system? Their paper, Uncertain<T>: A First-Order Type for Uncertain Data introduced a probabilistic programming approach that’s both mathematically rigorous and surprisingly practical. I found a copy of this paper while cleaning out my ~/Downloads folder over the weekend. I remember seeing it right around when Swift was announced, thinking it would be perfect for testing the new language’s generics. But I never got around to it, until now 🥲 As you’d expect for something from Microsoft in the 2010s, the paper is implemented in C#. But the concepts translate beautifully to Swift. You can find my port on GitHub: impo...