There Are Two Kinds of C# Libraries. The first kind helps you parse JSON or talk to PostgreSQL like a responsible adult. The second kind asks a much stupider and therefore much more interesting question: what if a variable could be influenced by the future? I built PositronicVariables as part of my QuantumSuperposition repo because I wanted to see whether Damian Conway’s gloriously strange old idea could be made to work as a real .NET library instead of living forever as conference folklore. The result is a time-looping variable container that simulates values evolving across iterative timelines, with automatic convergence, transactional updates, and telemetry. That sounds unreasonably dramatic for a C# package, which is exactly why I liked it. (GitHub) PositronicVariables QuantumSuperposition GitHub Under the hood, this is not really “quantum computing in C#”. It is constraint programming in a fake mustache and a lab coat. That framing is not me being cute after the fact. Conway himself described positronic variables as a form of constraint-satisfaction programming, just approached through a very loud metaphor. His habit, and one of the reasons his work is so much fun to read, was to take ideas from quantum physics and use them as a disciplined way to invent new programming models. The metaphor was weird, but the implementation logic was not random. (Global nerdy) Global nerdy That was the thing that grabbed me. Positronic variables sound like a joke until you look more closely. Then you realize they are a serious answer to a serious question: what do you do when the cleanest way to model a system is not simple forward execution, but mutual constraint, feedback, and repeated convergence? That is where the fun starts. So What Is a Positronic Variable? A normal variable is a tidy little box. You put one value in, you take one value out, and everyone politely agrees to pretend time is a straight line. A positronic variable does not behave that way. It participates in a loop of assumptions, consequences, and re-evaluation until the system lands on something self-consistent. It is not just “a value”. It is part of a causal negotiation. In my implementation, PositronicVariable<T> sits on top of the repo’s QuBit<T> superposition model and is aimed at feedback loops, recursive dataflow, multi-state unification, time-reversible computation, and timeline convergence. I split the repo deliberately: QuantumSuperposition handles multi-valued state and quantum-style operations, while PositronicVariables handles temporal convergence and causal feedback loops built on top of those semantics. PositronicVariable<T> QuBit<T> QuantumSuperposition PositronicVariables That probably sounds abstract, so here is the tiny demo from the README, which is still the cleanest way to show what the model is doing: var antival = PositronicVariable<int>.GetOrCreate("antival", -1);
Console.WriteLine($"The antival is {antival}");

var val = -1 * antival;
Console.WriteLine($"The value is {val}");

antival.State = val; var antival = PositronicVariable<int>.GetOrCreate("antival", -1);
Console.WriteLine($"The antival is {antival}");

var val = -1 * antival;
Console.WriteLine($"The value is {val}");

antival.State = val; This creates a feedback loop. antival starts as -1. antival -1 val becomes the negation of antival. val antival Then I feed val back into antival. val antival At that point the system has a problem. If antival is -1, then val is 1. But if antival becomes 1, then val should be -1. The value is now arguing with its own consequences. antival -1 val 1 antival 1 val -1 So the engine keeps iterating until it finds something stable, or until the only honest answer is that multiple states remain in play. In this case, the documented result is any(-1, 1) for antival and any(1, -1) for val, which is my runtime’s polite way of saying causality has become a group project. any(-1, 1) antival any(1, -1) val That example matters because it shows the library’s real personality. This is not just delayed evaluation. It is not just lazy computation. It is a convergence engine for circular definitions. Later logic can reach back and affect earlier reads because the system keeps replaying the loop until the values agree, or until agreement fails and the superposition remains. (DEV Community) DEV Community The Lineage Is Gloriously Short and Weird One of the reasons I liked building this is that the family tree is both clear and oddly tiny. The story really starts with Damian Conway’s earlier Perl work. Back in 2000, he released Quantum::Superpositions, which gave Perl values that could behave like several possible values at once. That was the key intellectual stepping stone. Before you can build variables that reconcile themselves across causal loops, you first need a model where a value can remain plural for a while without the whole runtime catching fire. (MetaCPAN) Quantum::Superpositions MetaCPAN From there, you get a few related branches. There was Quantum::Entanglement, which explored the idea of variables in superposition whose outcomes become linked. Observe one, and the others collapse consistently with it. That is close family. It shares the “multiple possible states” DNA. But it is still not quite the positronic trick, because the positronic part is not just superposition. It is backwards resolution through a causal loop. Quantum::Entanglement Then part of Conway’s superposition idea went mainstream, or at least mainstream by Perl standards, in Raku through Junctions. Raku’s Junctions are logical superpositions of values that autothread over operations and collapse in Boolean context. That is the respectable descendant of the same intellectual impulse. You get the “many possible values at once” half of the idea in a language feature that looks almost alarmingly normal. (Raku Documentation) Raku Documentation And then there is the actual positronic moment. In Conway’s 2008 OSCON talk, positronic variables were described as values that come into existence at the end of a block and travel backwards through runtime. That is a sentence that should get you removed from a normal architecture review, and I mean that as praise. The point was not to cosplay physics. The point was to model a certain class of problems by repeatedly rerunning the relevant logic until a consistent solution emerges. The public trail after that is surprisingly thin. There are talk notes, references, and the sort of reverent “I once saw Conway melt a room full of programmers’ brains” stories that gather around these things. What there is not, at least publicly, is a thriving ecosystem of maintained, installable positronic-variable libraries across every major language. That scarcity is part of what made me want to build one in C#. I did not want the idea to stay in the category of “legendary weird talk concept everyone cites and nobody ships.” I wanted to see what happened if I treated it as an engineering problem instead of a conference anecdote. Why I Thought It Was Worth Implementing For Real The easy joke is that this is just Schrödinger cosplay for .NET developers who got bored of dependency injection. The less stupid answer is that the model actually solves a real class of awkward problems. Some systems are naturally recursive. Some are dominated by feedback. Some are best expressed as mutually constraining states rather than as a neat top-to-bottom pipeline. And some problems want the system to keep revisiting assumptions until the entire graph settles into something coherent. That is the space I was aiming at. The broader QuantumSuperposition repo was already about uncertainty, multi-state computation, and algorithm experiments where “one value right now” is not always the best mental model. PositronicVariables was the point where that work started arguing with time as well. Instead of just allowing multiple candidate states, it gives those states a mechanism to push through a feedback loop and converge, or fail to converge honestly. QuantumSuperposition PositronicVariables That also meant I did not want this to stay at the level of a cute demo. One of the things I cared about while building it was making the package feel like engineering rather than theater. The README talks about transactions, retries, telemetry, thread-safety boundaries, and a single ConvergenceCoordinator that serializes the convergence engine while allowing ordinary multi-threaded updates to flow through transactional commit paths. Reads can take a validate-only fast path with no lock acquisition, while writes are staged and committed atomically. That is not how you build a joke. That is how you build something you expect people to poke, stress, and break in interesting ways. ConvergenceCoordinator I also wanted to keep the boundaries honest. This package is not claiming to be a universal theory of programming. It is not a quantum simulator, and it is not a magic replacement for sane state models. It is useful when you are dealing with recursive definitions, paradox resolution, distributed agreement models, non-linear recursion, and feedback loops where a straight-line mental model is the wrong one. It is not a thing you randomly staple onto payroll software because you got carried away after one conference talk and two espressos. Well, you could do that, but your coworkers would start backing away from your monitor and they would not be wrong. could Why This Stuff Stays Rare Because it is a pain in the neck. To make this ergonomic, you need a model that can intercept or wrap computation deeply enough to build a graph of consequences, detect cycles, replay state, and decide whether a loop has genuinely converged rather than merely vibrating in place like a shopping trolley with one bad wheel. That is hard. Conway’s original framing already leaned on repeated preprocessing and reruns for convergent algorithms. Bringing that into C# means formalizing convergence loops, cycle detection, timeline replay, superpositions, and conflict resolution in a way that developers can actually use without needing to sacrifice three goats to the type system. There is also a cultural reason this idea stays obscure. It lives in a weird gap. It is too exotic for mainstream application development, where people mostly want their variables to sit down, shut up, and hold exactly one value at a time. But it is also too specific, too metaphor-driven, and maybe too impolite to attract the academic crowd that would usually formalize this kind of thing into a respectable research area with papers, terminology, and approximately twelve Haskell libraries. If you want to work backward from constraints to consistent values, the academic world already has serious tools for that. Prolog exists. Logic programming exists. Constraint systems exist. But those approaches arrive through different machinery and different culture. Positronic variables arrive wearing a sci-fi badge and kicking the door open. Which is, frankly, part of the charm. Why I Still Think The Idea Matters I do not think positronic variables need to become mainstream to be valuable. Some programming ideas matter because they ship everywhere. Others matter because they widen the space of what you think code is allowed to do. This is one of the second kind. Once you spend time with a model like this, it becomes harder to assume that all computation must reason only forward. You start thinking more naturally about mutually constraining state, iterative stabilization, and values that are allowed to remain plural until the system has enough information to force a collapse. Even if you never put a positronic variable anywhere near production, that shift in perspective is useful. It makes certain classes of problem easier to see. It makes ordinary state models look a little less inevitable. And for five glorious minutes, it makes your regular C# variables look embarrassingly unimaginative. That alone is worth something. The Conclusion Most variables are obedient little boxes. You assign a value, you read a value, and everybody maintains the polite fiction that causality is neat and single-directional. Positronic variables reject that arrangement. They let later constraints push backward. They let cycles stay alive long enough to settle. And when a single stable answer does not exist, they let multiple outcomes coexist instead of lying to you with fake certainty. The result is half constraint programming, half temporal hallucination, and much more implementable than it has any right to be. Conway supplied the original deranged metaphor. Perl supplied the first superposition machinery. Raku normalized part of the idea. And I wanted to see whether C# could host the full causal weirdness without reducing it to a novelty. That is what PositronicVariables is. PositronicVariables Strip away the quantum jokes and the sci-fi perfume, and the pitch is actually pretty straightforward: sometimes the cleanest way to solve a problem is to let your variables argue with the future until they stop.

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Quant

Positronic Variables in C#: Teaching State to Argue with the Future

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

3 Excel Libraries Every .NET Developer Must Know

The Noonification: Will You Be My GPT-Valentine? (2/13/2023)

5 Performance Tips For .Net Developers

5 Ways to Add Security to Excel & PDF with .NET Document APIs

A Guide to Kubernetes Autoscaling Tools with Linode Kubernetes Engine

A Simple Safety Net For Async EventHandlers

3 Excel Libraries Every .NET Developer Must Know

The Noonification: Will You Be My GPT-Valentine? (2/13/2023)

5 Performance Tips For .Net Developers

5 Ways to Add Security to Excel & PDF with .NET Document APIs

A Guide to Kubernetes Autoscaling Tools with Linode Kubernetes Engine

A Simple Safety Net For Async EventHandlers

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps