miniblog.

Designing UIs is such a hard problem. Sometimes I try a bunch of options and I settle on "this one seems the least annoying".

I'm not sure if I should use the term "text diff" or "textual diff" to refer to a conventional, line-oriented diff of text in difftastic. Any opinions? Which seems clearer to you?

I frequently find myself running: $ slowish $ slowish | jq $ slowish | jq | grep I feel there must be a better way to build up pipelines incrementally without re-running. I could save each output to a file, but it's more verbose, and most of these tools have nicer output when stdout is a TTY.

There are *so many* ways that reading a text file can fail. Maybe it doesn't exist, it's a broken symlink, it's actually a directory, it's not the encoding you expected, or perhaps you just don't have the correct permissions. Reporting good errors is surprisingly labour intensive.

When writing long-lived programs (daemons etc) in Rust, I find myself asking *where* I should put data. In a GC'd language it's just "I have a string" but Rust forces me to find somewhere to put it. You do get a performance benefit for this work though.

On the challenge of writing accurate source spans on Unicode source code: https://reedmullanix.com/posts/unicode-source-spans.html Also (see footnotes) a fair number of LSP clients assume UTF-8 despite early versions of LSP mandating UTF-16!

I'm trying to decide the best voice for PL documentation. Passive: "`let` can be used with destructuring." Reader focused: "You can use `let` with destructuring." Describing the PL: "FooLang supports destructuring with `let`." Anyone have opinions or best practices?

I'm coming round to the view that a main function shouldn't take arguments. For example, in Rust you have to call std::env::args() to get CLI arguments. This makes Hello World less verbose, and gives you more flexibility in setting up CLI argument parsers.

The word "agent" is so overloaded in the AI space. Sometimes it means a sophisticated interaction system, but other times it just means API. I think it's partly a sign of how new the space is. We don't have consensus on the best way to use these systems yet.

I've seen "cons cells" and "cons pairs", but today I saw "conses", which is new to me. (Clearly Lisp has no downsides, only pros and cons! 🙃)

Is there any relationship between language adoption and the size of its standard library? These days it seems completely orthogonal, but early Java adopters spoke highly of the collections library compared with C++. Maybe it's the widespread availability of package managers?

Chekhov's repro: If a line of code is included in a bug report, it should contribute to the debugging somewhere.

Chekhov's repro: If a line of code is included in a bug report, it should contribute to the debugging somewhere.

I'm working on arity errors in Garden, my toy programming language. Rather than just saying "expected 3, got 4 arguments", I'm trying to report where the extra argument is, or what extra argument was expected.

It's interesting to see the "why not Rust?" discussions around the TypeScript news that they're using Go. It shows that Rust has reached a level of maturity that it's a default for some users. Go does seem to be in a sweet spot for AOT languages with GC though.