miniblog.

Writing type params with <> (e.g. List<Int>) seems the most natural to me: probably because I encountered that syntax first. Between C++, Java and TypeScript I think it's the most common too. List[Int] seems to be next most common (Scala, Python) but TIL Gleam uses List(Int)!

Anthropic used Claude to write a C compiler in Rust (CCC). I've really enjoyed following the discussion. The initial post shows how they wrote the harness with GCC as an oracle and a prompt specifying a design using SSA. The author has clear domain expertise. https://www.anthropic.com/engineering/building-c-compiler

Agentic programming workflows rather remind me of genetic programming. The agent has a validation step that looks like a fitness function, and both run iterative trials.

I'm still not sure whether a language should include a "kitchen sink linter" like Rust's clippy or have a package oriented "thousand flowers bloom" linter like eslint for JS and TS. Clippy is delightful out of the box but eslint makes it so easy to have project specific lints.

Is there a good term for "after using this feature we realised that the best design is different from the current design"? In casual conversation I generally hear "bug" but there was nothing wrong with the original implementation.

I'm super impressed by how many lint rules can be implemented with just eslint's no-restricted-syntax and selectors. Example: { selector: "ExportNamedDeclaration[declaration=null][source=null]", message: "Add `export` directly to the function instead of a block export." }

There's something pleasingly self-referential about configuring an agent by talking to it. > Remember that [fact about data formats]. Agent: Noted. ... realise nothing happened ... > Write to your rules file that when I say "remember", I want you to write to the rules file.

Should lint suppressions be first class syntax or comments? Adding a proper metadata system (e.g. Clojure or Rust) is a big design space but it's clear which expressions are affected. Comments are much easier to implement but it's easy for users to get them wrong. Thoughts?

I enjoyed this article about personal project programming, but I particularly liked this definition: "Production code has a phone number to call when it breaks"

One fun way of testing new AI models: take an existing codebase you have and just ask them to "review it and fix bugs". In principle this should find more issues over time as models get smarter. I've found a few bugs this way at least.

Cleaned up an old git repo of Ansible playbooks and it's amazing how much is just Docker now. Docker handles process supervision, centralises logging, and containers coexist without issues. It's nice when things get simpler.

After further playing with my LLM project, I'm surprised how hard it is to tune with system prompts. My agent kept saying "obviously" even though my prompt said "helpful, professional". Eventually I found that a "courteous" prompt gets "of course" which is better but not ideal.

I've been tinkering with an LLM interface with my calendar and it's really nice to use. "Delete my April trip" is a lot less fiddly than opening calendar, switching to the month view, scrolling to April and so on. I should probably build an undo as well though.

Today I learnt about "bypass charging", a phone feature where it can run directly off the mains without using the battery at all. No battery charging, less heat, less battery wear. Nifty.

I'm considering using WebP more: for example, my websites would load faster and browsers have supported it since 2020: https://caniuse.com/webp That said, GitHub just added support in August 2025, so I suspect I'd still find use cases that don't work yet: