Functional core, thin bridge

Four of my projects look unrelated — a Balatro for smart glasses, a three-game card room, a chess engine, an agent-status HUD — and they are all built the same way underneath. An immutable game or app state. Reducers that take a state and an action and return the next state, with no side effects of their own. A dumb view that turns state into display, carrying no logic. And every messy thing — the Bluetooth radio, the canvas, the disk, the network — quarantined in a thin bridge at the edge.

The reason is testability, and the payoff is concrete. Because the core is pure, the entire game logic runs with no hardware in the loop. G2 Balatro's thirty jokers, its real chips-times-mult scoring, its shop and boss blinds and save-and-resume, are covered by 136 tests that never touch a pair of glasses. The chess engine's legal-move generation, its draw rules, and its minimax search are plain Dart you can assert against on a laptop. The card room returns a new state on every transition instead of mutating, which makes the rules unit-testable and the bugs reproducible.

The bridge is where the platform lives, and keeping it thin is the discipline. The glasses SDK and the radio calls are a small adapter that the core never imports. When the hardware is absent — no glasses connected — the app swaps the bridge for a browser preview with a keyboard standing in for the temple tap, and the same untouched core runs in a tab. The hardware becomes the last inch, optional to everything above it.

This is the functional-core, imperative-shell idea, and the value compounds across projects. Once the shape is in your hands, every new app starts the same way: model the state, write the reducers, prove them with tests, then bolt on whatever screen and radio the target platform demands. The weird hardware stops being the hard part, because by the time you reach it, the thing it is displaying already works.