Blackjack in Phosphor: A Door Game as a Language Test

Sat, 19 Sep 2026 00:00:00 +0000

Every language looks fine in its own test suite. The tests were written by the same people who wrote the language, with the same blind spots. The only honest benchmark is a program someone actually wants to run.

So when the question came up — “would it be easy to create a simple blackjack game for the BBS?” — the answer was: yes, and that’s exactly the test Phosphor needs. Blackjack is a sweet spot for a scripting language’s first real workload. It has genuine state (a shuffled deck, two hands, a bankroll), real control flow (a dealer AI that hits to 17, ace soft/hard counting), string wrangling (card glyphs), user input, and persistence. If the parser, the evaluator, and the door bridge can carry all of that, the language is real. If they can’t, we find out where.

UserDefaults for a BBS: A Generic Preferences and State API

Sat, 19 Sep 2026 00:00:00 +0000

Every non-trivial app eventually faces the same question: where does small user configuration live, and where does user data live? macOS answered this decades ago with two separate systems — UserDefaults for typed, user-visible settings, and the file system for documents. We had been living with neither, and it showed.

The mess we had

Phosphor already had a real preference engine. PreferenceResolver resolves settings through three levels — user, then group, then global — backed by the database, cached with proper invalidation, and connected across processes with Postgres LISTEN/NOTIFY. Screens could even bind to a preference reactively, so flipping a toggle redraws every open screen instantly. For the language side, .phos scripts read settings with pref("key") and write them with set_pref("key", value).

Phosphor on Phosphor BBS

Blackjack in Phosphor: A Door Game as a Language Test

UserDefaults for a BBS: A Generic Preferences and State API

The mess we had