Matthew Hammer and Hazel

Livelits, making them fast, and games my kids design

Hazel#

Hazel is a live functional programming environment: every edit state has a meaning, so a program has a type and a result even while it is incomplete. Hazel is developed by Cyrus Omar's group at the University of Michigan. I co-authored the first Hazel papers and its founding grants, around 2017, and since this fall I have been working on it again.

What I'm working on#

Livelits are GUIs for Hazel values, written as ordinary Hazel code and living inside the program they edit: a slider for a number, a color picker, a figure you pose by dragging. I'm working on user-defined livelits, ones that a Hazel programmer writes, and on making them fast enough to feel like plain apps: moving a slider should redraw a picture as quickly as it would in a small JavaScript page.

That makes it a performance question, and most of my Hazel work right now is answering it, on two pull requests: hazelgrove/hazel#2635 (livelits with modular editors) and #2597 (the full livelits branch). The performance tracking issue is #2609.

Performance reports#

The Hazel performance analysis series explains that work for anyone following it. Each report takes one question (is it really that slow? where does the time go? what fixed it, and what's left?) and answers it with measurements. Newest first:

  1. ^report(15) Dress Up and its livelits, side by side2026-10-15
  2. ^report(14) What the page keeps from one edit to the next2026-10-14
  3. ^report(13) Telling the request what changed2026-10-14
  4. ^report(12) Moving a group, not its points2026-10-13
  5. ^report(11) Naming what a slider leaves alone2026-10-13
  6. ^report(10) What a slider change touches2026-10-13
  7. ^report(9) Names and reuse: what fresh ids cost Hazel2026-10-13
  8. ^report(8) One slider, three ways: what modular editing saves2026-10-12
  9. ^report(7) Five minutes to the first picture2026-10-12
  10. ^report(6) Catching performance regressions in CI2026-10-12
  11. ^report(5) Two threads, one picture: the worker, the page, and diffing the view2026-10-12
  12. ^report(4) The witch and her woods, ported to Hazel2026-10-11
  13. ^report(3) A day of requests from M and N2026-10-11
  14. ^report(2) From a game to a slide deck: Messed Up Dress Up in Hazel2026-10-11
  15. ^report(1) Why a slider isn't instant yet2026-10-10

The series and its source: matthewhammer.org/hazel/performance-analysis/ and on GitHub.

Games with my kids#

The test bed is a set of small games whose features my kids, M and N, choose as they play. The first is Messed Up Dress Up, a paper doll with every part on a slider, and costumes, places and music to go with it. Each request goes live as soon as it's ready, so the next round of play tests it.

The game is a plain JavaScript page, and it redraws in milliseconds. Its toys are then rebuilt in Hazel, as user-defined livelits on the Livelit Playground, where they first took seconds. Closing that gap is what the reports measure. The games' code is on GitHub.

More on what Dress Up is for, and every version of it kept day by day: its music, with a player, and its pictures.

How I work#

I work with Claude, Anthropic's AI model, as a partner for the code, the measurements and the writing. The Hazel Work Dashboard shows what we're working on, as it stands: the current ticket, the queue after it, and the pull requests we track. It, its history and our work notes are public on GitHub, though written for the two of us; the reports are the version for everyone else.

Fumola in Hazel#

Fumola, my current language, with Adapton's primitives for incremental computation built in, also runs inside Hazel documents, as described on its Hazel integration page.