To that end, using AI seems like a great solution!

As a human there might not be a finite list of criteria for what makes a puzzle interesting. But if I give the model enough positive and negative examples, there's a chance (but not guarantee) it might pick up on some patterns.

This is a good starting point, but depending on the puzzle type, your artifacts might still feel very randomly generated, so you might still need a human curation process.

Many puzzles are like constraint-satisfaction problems (CSPs). One strategy I tried was to generate puzzles at random and rank them to:

- minimize the # of constraints, since elegant puzzles have fewer moving parts
- maximize the search tree complexity, so mentally finding the solution feels hard

In college I used to hack around with writing code to generate grid-based pencil and paper puzzles like Sudoku, Numberlink, etc. So I love this stuff.

Teaching a computer to solve puzzles is straightforward once you have the algorithm down. But how do you make it generate puzzles that feel "human"?

Two other aspects that make EarPods feel more shareable:

1. They're cheap - it's low risk if they're damaged
2. They don't have sensors detecting if they're in your ears or not. Most apps pause music if you take an AirPod out of your ear. Great for solo use, not for sharing

(IMO the other factor here is that it's still hard to formally model systems -- harder than traditional programming, arguably. It's a totally different skill set. I have a math undergrad degree and proof /model checking software still intimidates me a little bit!)

The reality is that these are orthogonal statements; they don't conflict.

But there are times when it feels like they do, because software engineers often want to believe there's a best way to build software. And in practice, software robustness is a sliding scale.

Takeaways for me:

- When your language compiles to C, you get a really nice portability story.
- Macros can used to bridge the gap between functional and imperative syntaxes.
- One way to make your language more REPL-like is by letting macros run code to interact with the LSP server (see img)

What I would find more useful than static analysis to identify pure functions, would be tooling that reads my programs and identifies what non-trivial "pure" parts can be split out into pure functions. Or that figures out how to unit test / create deterministic simulations of complex APIs.

What I'm not sure about is what are the concrete type checking or compilation or DX benefits elevating pure functions to some different class or rank in a PL.

This leads me to wonder if it's better for DX to treat pure functions instead as the exceptional case.

In practice, this rings true -- if I find some code that's purely manipulating data structures, that's where I try to extract it into a pure function.