DEV Community: Matt I Michie

Building a Programming Language for Fun

Matt I Michie — Tue, 17 Feb 2026 01:23:51 +0000

I've been building a programming language. It started as an experiment and turned into sixty thousand lines of Go. That's what happens when you try to answer the question: what would a language look like if Lisp and Python had a kid?

The Premise

I've always liked two things about Lisp that most people hate: the parentheses and the homoiconicity. Code is data, data is code. It's a simple idea with deep consequences. Macros work because you're manipulating the same structures the interpreter reads. There's an elegance to it that never wore off for me.

But I also write a lot of Python. Python gets things right that Lisp never bothered with: readable syntax for common operations, a pragmatic standard library, data structures that do what you expect without ceremony. Python's dict comprehensions are nicer than anything Lisp has for the same task.

So I built a language that tries to have both. S-expressions when you want them, Pythonic syntax when you don't. The same interpreter handles both:

# Lisp style
(def factorial (n) (if (<= n 1) 1 (* n (factorial (- n 1)))))

# Pythonic style
def factorial(n): (if (<= n 1) 1 (* n (factorial (- n 1))))

You can mix them freely. The parser desugars the Pythonic forms into the same AST. Under the hood, it's all S-expressions.

What I Actually Built

The interpreter is written in Go, which turned out to be a good choice for a language runtime. Go's interfaces map cleanly to the kind of type dispatch a dynamic language needs. The garbage collector handles memory management for hosted objects without me having to think about it.

The feature list got long. Classes with inheritance and method resolution order. A protocol system with Python-style dunder methods so you can define __add__ and __getitem__ on your own types. Exception handling with proper tracebacks. Generators with yield. List comprehensions, context managers, f-strings. Most of the Python features I actually use day-to-day.

The protocol system was the most satisfying piece to design. Operator dispatch goes through three tiers: check for a dunder method first, then a protocol implementation, then fall back to type-based defaults. It means the language is extensible in the same way Python is. Define __iter__ and __next__ on your class and for-loops just work.

I also spent time on Python standard library compatibility. Pure Python stdlib modules can run directly when possible. For C extension modules, I wrote Go stubs that provide the same interface. The goal isn't perfect compatibility. It's enough compatibility that useful code works without modification.

The Architecture Rabbit Hole

At some point I started thinking about what this could become if the architecture was right. The idea is a multi-frontend, multi-backend design: multiple source languages parse into a shared intermediate representation, which can target multiple backends.

Right now there's one frontend (M28's hybrid syntax) and one backend (a tree-walking interpreter). But the architecture is designed so a Python frontend could parse into the same IR, and a bytecode VM or LLVM backend could execute it. Solve the problem once in the middle layer and every frontend/backend combination benefits.

I've designed the bytecode VM on paper. Register-based, targeting a 3-10x speedup over the tree walker. Haven't built it yet. The interpreter is fast enough for everything I use it for, and there's always another language feature that's more interesting to implement than making the existing ones faster.

Why Build a Language

People don't ask "why" as much as you'd expect. Maybe because the answer is obvious: because it's interesting. You learn things building an interpreter that you can't learn any other way. How scoping actually works. Why tail call optimization matters. What makes a type system feel good to use versus feel like it's fighting you.

Every language is a set of opinions about how programmers should think. Building one forces you to articulate your own opinions and then live with the consequences. I think operator overloading should use protocols. I think immutable data should be the default. I think S-expressions are underrated. Now I have a language that embodies those opinions, and I can see where they work and where they don't.

It's also the longest-running side project I have. Languages are never done. There's always another feature, another optimization, another edge case in the parser. It's the kind of project that rewards showing up for an hour on a Tuesday night, making one thing slightly better, and closing the laptop.

The code is on GitHub if you're curious. It's a toy in the sense that I wouldn't deploy it to production. But it's the most instructive toy I've ever built.

Simulating Blackjack the Hard Way

Matt I Michie — Tue, 17 Feb 2026 01:16:53 +0000

I built a blackjack simulator. That sentence undersells it. What I actually built is a 28,000-line Python framework for simulating card games with an event-driven architecture, immutable state management, and realistic shuffle physics. For blackjack.

This is what happens when a software engineer gets curious about casino math.

The Itch

It started the way these things always start: I wanted to understand the numbers. Not the hand-wavy "the house has a 0.5% edge" stuff you read online, but the actual mechanics. How does basic strategy change when the dealer hits soft 17? What does card counting really buy you? How many riffle shuffles does it take before a deck is actually random?

I could have read a book. Instead I wrote a simulator. Then I rewrote it. Then I rewrote it again.

Getting the Simulation Right

The first rule I set for myself was no shortcuts. If you're simulating blackjack to understand blackjack, you can't approximate the parts you find inconvenient. Every card comes from a shoe. Every shuffle follows real physics. Every hand resolves by the actual casino rules: splits, doubles, surrender, insurance, the whole mess.

The shuffle simulation is where things got interesting. A perfect Fisher-Yates shuffle is trivial to implement, and it produces a uniformly random deck. But casino dealers don't perform perfect shuffles. They do riffle shuffles, and the mathematics of imperfect riffles are well-studied. It takes about seven riffle shuffles to adequately randomize a deck. Fewer than that and there's exploitable structure left in the card order. I implemented three shuffle types with configurable fidelity so I could study exactly how much information survives an imperfect shuffle.

Card counting was the other rabbit hole. The basic Hi-Lo system is straightforward: low cards add one, high cards subtract one, divide by decks remaining. But professional play deviations are where it gets complicated. The correct play changes based on the true count. Sometimes you should hit a 16 against a dealer 10. Sometimes you shouldn't. The threshold depends on how deep you are into the shoe.

I implemented all of this because I wanted the numbers to be right.

The Architecture Obsession

The simulation code worked fine as a monolith. I could run thousands of hands and get statistically valid results. But I kept looking at the code and seeing things I wanted to fix.

The game logic was tangled up with the I/O. Strategy decisions were coupled to hand resolution. State was mutable and scattered across half a dozen objects. It worked, but it was the kind of code that made me uneasy. The kind where adding a new feature meant understanding every other feature first.

So I did a four-phase rewrite. Event-driven architecture, immutable state with frozen dataclasses, platform adapters to decouple the engine from any specific interface, and async support throughout. The kind of engineering that is completely unjustifiable for a side project and completely satisfying to build.

The core insight was treating every state change as an event. A card is dealt: that's an event. A player hits: event. The dealer reveals their hole card: event. This makes the game engine a pure state machine. Feed it actions, get back new states. No side effects, no hidden mutations, easy to test, easy to verify.

It also means you can record an entire game as a sequence of events and replay it later. When my simulation produced a result that looked wrong, I could step through every decision and see exactly where the math diverged from my expectations. Usually the math was right and my expectations were wrong.

What 350,000 Hands Per Second Tells You

At this point the simulator can run about 350,000 games per second. That's enough to get statistically meaningful results on almost any question you want to ask.

Some things I've confirmed that you probably already knew: basic strategy works. Card counting works, barely, under ideal conditions. The Martingale betting system is a reliable way to go broke slowly.

Some things that surprised me: the variance in blackjack is brutal. You can play perfect basic strategy and lose for hours. The math says you'll come out slightly ahead over thousands of hands, but "slightly" is doing a lot of heavy lifting in that sentence. I have a much better intuition now for why card counting requires both a large bankroll and an iron stomach.

Why Build This

People build side projects for different reasons. Some want to ship a product. Some want to learn a technology. I wanted to understand a system, and building a simulation was the most thorough way I knew to do it.

The architecture work was its own reward. Not because anyone will ever need an event-driven blackjack engine with immutable state management, but because the patterns transfer. The same separation of concerns that makes a card game testable makes a distributed system debuggable. The same event-driven approach that lets me replay a hand of blackjack is the same approach that lets you replay a production incident.

The code is on GitHub if you want to look at it. Fair warning: it's a side project that kept growing. Twenty-eight thousand lines of Python for a card game. Some projects are just like that.

Nixifying My Dotfiles

Matt I Michie — Tue, 17 Feb 2026 01:14:16 +0000

I wrote about bootstrapping my dotfiles a few days ago. Homebrew, GNU Stow, a bootstrap script. It works on my Mac. The problem is I also use Linux, and the Brewfile is worthless there. Every time I SSH into a Linux box I end up cloning the repo, running stow.sh for the configs, and then installing packages by hand for twenty minutes. Same tools, different package managers, nothing shared.

I'd been putting off trying Nix because it looked like a lot of ceremony for what is fundamentally brew install plus symlinks. But the cross-platform thing kept nagging at me, so I made a branch and started experimenting.

The Stack

nix-darwin handles system-level macOS configuration: defaults, Homebrew casks, system packages. home-manager handles user-level everything: packages, dotfile symlinks, shell setup. Both are configured through Nix's functional language and the whole thing is pinned with a flake.

On macOS, darwin-rebuild switch applies the entire stack. On Linux, home-manager switch handles the user side. Same repo, same package list.

Restructuring

The old repo had one directory per tool in stow's expected layout: zsh/.zshrc, nvim/.config/nvim/init.lua, git/.gitconfig. Stow would symlink each directory's contents into $HOME.

I moved everything into a configs/ directory and let home-manager handle the symlinks with mkOutOfStoreSymlink:

home.file.".zshrc".source =
  config.lib.file.mkOutOfStoreSymlink "${dotfiles}/zsh/.zshrc";

mkOutOfStoreSymlink is important. Without it, Nix copies files into /nix/store/ and the symlink points there, read-only. With it, the symlink points back to the git working tree, so I can edit configs and see changes immediately. Same behavior as stow.

Packages

The 345-line Brewfile became a home-manager module. All CLI tools go in one list:

home.packages = with pkgs; [
  ripgrep sd fd fzf zoxide
  eza bat dust duf procs
  xh delta difftastic hexyl
  starship atuin vivid gum
  hyperfine just watchexec tealdeer tokei
  shellcheck neovim tmux
];

Plus another 80 or so for Go, Rust, Python toolchains, infrastructure tools, network utilities, media processing. Everything was in nixpkgs. Two packages had different names: git-delta is delta in nixpkgs, and dust is du-dust. Everything else matched.

GUI apps can't come from Nix on macOS because .app bundles don't work well in the Nix store. nix-darwin has a Homebrew integration module that manages casks declaratively:

homebrew = {
  enable = true;
  onActivation.cleanup = "zap";
  casks = [
    "ghostty" "wezterm" "google-chrome"
    "docker-desktop" "slack" "1password"
    "aerospace" "spotify" "vlc"
  ];
};

cleanup = "zap" removes any cask that isn't in the list. So if I install something to try it and don't add it here, it gets cleaned up on the next rebuild. The cask list becomes the source of truth instead of whatever accumulates on the machine over time.

macOS Defaults

The osx/.osx script was 165 lines of defaults write commands. nix-darwin replaces it with typed options:

system.defaults.dock = {
  tilesize = 57;
  autohide = true;
  autohide-delay = 1000.0;
  mru-spaces = false;
};

These get applied on every darwin-rebuild switch. If a macOS update resets something, the next rebuild puts it back. I don't have to remember to re-run a script.

The Rust Binary

My custom starship-segments binary was previously compiled locally with the Homebrew-provided libgit2 and the resulting binary committed to the repo. With Nix, Crane builds it as a proper derivation:

starshipSegmentsFor = system:
  let
    craneLib = crane.mkLib nixpkgs.legacyPackages.${system};
  in
  craneLib.buildPackage {
    src = craneLib.cleanCargoSource ./starship-segments;
    strictDeps = true;
    buildInputs = pkgs.lib.optionals pkgs.stdenv.isDarwin [
      pkgs.apple-sdk_15 pkgs.libiconv
    ];
  };

This actually caught a real problem. The old binary linked against /opt/homebrew/opt/libgit2/lib/libgit2.1.9.dylib. When I removed Homebrew packages in favor of Nix, that library vanished and Ghostty wouldn't even open because the tmux launch script called starship-segments during prompt setup. dyld error, immediate crash. The Nix-built version pins its own libgit2 in the store, so the dependency is always satisfied.

Crane also handles cross-platform automatically. The flake defines the build for aarch64-darwin and x86_64-linux, so the binary gets compiled for whatever system you're on.

The Flake

The flake.nix defines two entry points:

darwinConfigurations."mims-mbp" = nix-darwin.lib.darwinSystem { ... };
homeConfigurations."mim@linux" = home-manager.lib.homeManagerConfiguration { ... };

Both import the same shared modules. The darwin config adds system defaults and Homebrew casks. The linux config just sets the home directory. A justfile wraps the platform detection:

# Apply everything — auto-detects macOS vs Linux
just switch

Bootstrap on a new machine is three commands:

curl -sSf -L https://install.determinate.systems/nix | sh -s -- install
git clone https://github.com/mmichie/dotfiles ~/src/dotfiles
cd ~/src/dotfiles && just switch

What Broke

Two things, both the same pattern: hardcoded Homebrew paths.

My Ghostty launch command runs ~/bin/tmux-attach-or-new, which had TMUX=/opt/homebrew/bin/tmux on line 3. tmux was now in /etc/profiles/per-user/mim/bin/tmux courtesy of Nix. Ghostty showed a "failed to launch" error and wouldn't open at all. Fix: use command -v tmux instead.

The starship config had command = "~/.config/starship/starship-segments git", pointing to the old stow'd binary. The Nix-built binary was on PATH but at a different location. Fix: change it to just command = "starship-segments git".

Both were five-minute fixes, but the first one locked me out of my terminal until I figured it out.

Where It Stands

The experiment is on a nix branch. I've been running it on my Mac and everything works: prompt, tmux, all 120+ CLI tools, macOS defaults, casks. nix flake check passes.

The real test is the next time I set up a Linux box. If home-manager switch --flake .#mim@linux gives me my full shell environment in one command, I'll merge the branch. That's the whole reason I did this.

The Nix language took some getting used to. It's functional, it's lazy, and the error messages are occasionally unhelpful. I spent more time reading documentation than writing configuration. But the old setup was four scripts run in the right order on the right platform. The new setup is just switch on either.