miniblog.

I've started keeping a list of particularly interesting bugs and patches that I've worked on: https://github.com/Wilfred/interesting-code The time that I once removed *a single closing paren* in Emacs is still my favourite.

Playing with Claude and my new programming language has made me add features that it wants. I think they're reasonable. `for method in methods` -- custom syntax error explaining that `method` is a reserved word `echo 'println("hello world")' | garden` -- eval snippets from stdin

Playing with optional type signatures in Python, I realise that the return type is the most important to me. I'd much rather have a function with only a return type instead of a function with only parameter types. It's often quick to add too.

Make defaults to a single worker, and newer build tools (e.g. ninja) default to the number of physical CPUs. I wish there was an option for 'leave me a little bit of my machine to do stuff'.

One nice feature of cargo that I wasn't previously aware of: you don't need to do anything after updating your Cargo.toml. In npm, you need to remember to `npm i` after changing package.json. It's not declarative and the state can get out of sync.

I'm changing method definition syntax in my language: // old fun (this: Int) inc(): Int { this + 1 } // new method inc(this: Int): Int { this + 1 } The original syntax was inspired by Go, but the new syntax is more grep-friendly and perhaps more readable. Not sure about the verbosity though. Thoughts?

I'm still experimenting with UIs for live (sandboxed) evaluation of tests. I've realised that you really want to highlight the failing assertion, not just the failing test. Feedback welcome :)

Just released a new version of difftastic! * Verilog support * Improved Erlang, F#, Gleam, Pascal and Swift * Better detection of binary files

I find it fascinating how some businesses have scheduled downtime for their websites (e.g. my electricity provider last weekend), but others don't. I suspect it's primarily culture. You generally need to turn off electricity to do work, so your other tooling may reflect that.

Zig shipped a RISC-V backend before AArch64! I think RISC-V is doing really well in the technology enthusiast community.

One cute feature of markdown I'd not noticed before: there's no syntax for images *without* a description (i.e. alt text). 

When a tool supports both regular expressions and literal strings, which should be the default? If you default to regex, users can match more strings than they realise (e.g. `foo.txt`) or less (e.g. `foo(bar)`). I typically see regex as the default, but I prefer the opposite.

There are docs resources like https://diataxis.fr/ that categorise documents based on format and intended audience. They don't say where you should start, or what order you should write docs. I'm currently thinking README > reference > tutorial > how-tos. Agree/disagree?

I'm still tinkering with the website for my PL experiment. I want the styling to express "labour of love hobby project". Choosing what program to show on the home page is really hard too. All the keywords are links like Racket. What do you think?

I regularly see the phrase "all Xs are Ys, but not all Ys are Xs" in teaching material. Even material for children! I have to re-read it every time. I very much prefer "Y is a more general category than X" or "X is a subset of Y". Do people find this phrasing helpful, or is it poor pedagogy?