Laurence Tratt

One surprising thing about writing a compiler is the variance in day-to-day productivity. Some days I write fewer than 10LoC. Some days, like today, 1500LoC is possible. Even more surprisingly, the former days are much more taxing than the latter!

Train announcements continue to surprise: "we're running late because a train ahead hit a swan".

Indeed, that's probably even more common in web/email than `null`, at least in my experience!

I sometimes wonder to myself: what do normal folk think when they see the result of a (classic) software bug like the below?

There was a referendum on changing the voting system in 2011, so the precedent has been established that any similar change will need to take the same route. That changes the calculus somewhat.

Another person has left a negative review for our local graveyard.

That book is partly what made me think this way! I knew the high-level story, or thought I did, but I came to understand I only knew part of the story. Alas I can't remember who/where I saw it recommended to thank them!

New post: Why Firsts Matter tratt.net/laurie/blog/...

The idea that static types mean you don't need tests has done our field a great disservice IMHO. I test the life out of systems I write that use all sorts of type system features to make it hard/impossible to represent many unwanted states, because so many unwanted states are still possible.

There's a reason I only partly agree with the article! But that doesn't mean it's not useful for making me wonder if we've over-emphasised one solution to the problem (in the same way that the article might over-emphasise another solution). [As often in life, I suspect the middle is nearer optimal.]

I tried studying that book intensely early in my career, and I learnt a lot from it, thought not always in the ways I expected. Looking back, maybe the first 40% or so is quite profound and changed how I think about OO; the remainder was so far over my head that I could not form a judgment on it!

Personally, for expert programmers, I would like access to rigorous type systems *and* different architectures of software systems. There are some obvious contenders, but they've rarely been tried at scale IMHO.

I like articles which challenge our assumptions, even when I only partly agree with them. This article posits that type systems in programming languages are a poor substitute for different architectures of software systems. programmingsimplicity.substack.com/p/type-check...

It's muddy as there are many `vi`s (or, at least, many forks). On OpenBSD the base `vi` is basic and not extendable. OK for quickly editing a config file, but not much else IMHO. `vim` (or `neovim` as I now use) is a huge, customisable beast in comparison, that can be turned into an IDE if you wish.

Related to that is the challenge of scale: some language features only turn out to be a good or bad idea when you try them on big (big!) problems. And then we're in a combination of chicken-and-egg-land and lotteries whilst we wait for people brave enough to take the risk and report back.

When I upgraded my OpenSSH a couple of weeks back, I started getting some surprising (to me) warnings when using GitHub. I'm not sure I'd enjoy being the person who has to upgrade the fleet of servers that are now being fingered as culprits!

Perhaps due to narrowness of thinking on my part I think any plausible CPU will have to have a fixed, and fairly small, amount of "quick access slots" whether those are registers, a stack, or something else (e.g. the Mill's belt).

Register allocation is one of those things that seems like it should take 2 days to implement. Everyone I've ever spoken to about it has found all sorts of surprises that cause those 2 days to balloon. This great post will save future folk much time! bernsteinbear.com/blog/linear-...

Not quite: it's `void` in disguise as it consumes arbitrary number of arguments and doesn't return them!

I have been a Unix user for a... long time... yet only today did I accidentally discover that `:` is a built-in shell no-opt.

Finally, 3 years and 3 months after I bought a Framework laptop, there is an update for the (frankly, pretty poor) BIOS. But... it doesn't work. It says it does, but nothing is updated. Thankfully I eventually stumbled on this post community.frame.work/t/unable-to-... -- what a pallava!

Indeed, I'm increasingly noticing obvious mistakes in English subtitles for English language programmes. Which is... interesting.

I've noticed that even if I have only a passing familiarity with the on-screen language, there'll be clear oddities in the subtitles. Sometimes it's due to compressing lots of speech to a smaller amount of text, but sometimes it seems just plain ... wrong or, at least, suboptimal.

I'm interested to see if that is what happens. It seems to me like it should -- but, as yet, I'm not seeing much reflection on the matter. Perhaps it's just a matter of time!

New post: LLM Inflation tratt.net/laurie/blog/...

If I gave the impression that I didn't think that reviewers who go down this route should not be equally punished, I apologise. It seemed so obvious to me that they should that I (foolishly, in retrospect) didn't think to make it explicit.

I assign blame to actions: when it can be proven that an individual reviewer has used an LLM for their review, name and shame them, because they absolutely deserve their misconduct to have consequences!

By all means, help the community find out who the bad reviewers are (which requires telling someone that you're doing so!): but trying to exploit other's moral weaknesses for one's own gain is not a valid excuse.

If the authors had prenotified someone of what they were doing, then I would applaud them for trying to help us discover bad reviewers. As yet, there is no suggestion this is what any of them did AFAIK. [The analogy is imperfect, of course; analogies nearly always are!]

Indeed. My analogy is that the authors slipped a brown envelope with cash in with their paper and if the brown envelope came back unopened their defense is "I didn't bribe anyone, because they didn't take the money". But they still tried, immorally, to take advantage of other's immorality.