Laurence Tratt

Indeed.

To take a current topic: can it generate a compiler whose output is on a par with gcc/clang?

That's a very valuable piece of information because if it can do it now, it will never cost more in the future -- and it will probably cost less!

In the past fortnight, 50% of my conversations have seen me say "today's AI cannot do that and we have no idea if and when it will".

In the other 50% I've said "today's AI can do that, really, and you just need to try it".

Our collective calibration is currently very wonky!

Good, we need someone to research how to make it work everywhere as that is not yet a fully solved problem!

I'm glad to hear it's been useful to you!

This has saved me 950LoC in one Rust program alone. Comments welcome -- I definitely consider this experimental right now! github.com/ykjit/test_s...

Scratched a Rust itch with an experimental new crate `test_stubs`. I have traits with lots of methods. "Proper" code should implement all methods, but test code need not. `test_stubs` means that test code doesn't have to manually create `todo!()` methods.

If it was, it went straight to the 3 year old stage, and got the same response 3 year olds are familiar with -- "don't do that".

There's nothing more surprising than an agent, in the middle of doing some useful refactoring, asking if it can run a Python script which solely prints "HI" (yes, in uppercase) to stdout.

If you're thinking of applying to PLISS, you've got three days left! pliss.org/2026/registr...

A first: I awoke to a PR on one of the Rust projects I maintain that results from a proposed fix to a rustc oversight. Our code should never have compiled, IMHO, so the rustc fix is a good one!

For those interested in the rustc change: github.com/rust-lang/ru...

This is definitely a book I need to reread. Honestly, I read it in the past in part because he grew up near me. I soon realised I was in the hands of a master, even if I didn't quite understand the depths of that.

When I read Walter Bagehot's (d. 1877) "The English Constitution" years ago, I was surprised at how much time he spent contrasting it to the US constitution. I now realise he had thought deeply about the plausible futures of both and how they could adapt and/or go wrong.

Of course. But that is not the only metric worth considering.

I need to go backwards in many cases, and I then lose all the mental state I've built up. `printf` allows me to refresh that mental state. Certainly, it's served me very well for a long time, at least before reverse debuggers.

It's so good that I am willing to overlook how terrible the (gdb) debugger UI is. I don't need most of the weird hard-to-remember features, as they're much less necessary (for me) when reverse debugging.

Reverse debugging, specifically `rr`, has changed this calculus for me. By starting at the error and working backwards (and sometimes forwards), I have a sort of uber-powerful `printf` that allows me to examine the trail.

I've never been a fan of debuggers. Examining the state at the point of a crash rarely helps me: the problem is nearly always earlier in time. `printf` is more useful to follow the trail forwards.

A reminder for those interested in PLISS 2026: there are 10 days left to register your interest. pliss.org/2026/registr...

Even though I know from past experience how important it can be to avoid small memory allocations in performance critical code, the measurable effect of removing them still often surprises me.

tratt.net/laurie/blog/...

I was recently asked how I choose what podcasts I listen to, and paused. Then I realised it's similar to how I choose what to read. In particular, for current affairs, I actively try to avoid just reinforcing my current opinions. I think this has helped make me wrong less often!

Low-needle-drop Christmas trees are willing to delay their revenge: they wait until you remove them from the house before dropping dry, sharp, needles everywhere.

I believe that was the verdict of, well, everyone ;)

Now you can see what I ended up doing... Whether it worked and anyone enjoyed it is a very separate matter ;)

YouTube video by Laurence Tratt Some Things I've Learnt About Software

These are things that we can easily miss day-to-day, and in the rapidly changing technological landscape. There's lots of new-to-me stuff in here, not all perfectly formed yet, but perhaps of interest to some.

A few weeks ago I gave a talk "Some Things I've Learned About Software" that was unusual for me. I didn't program in it once. I didn't mention specific technologies. Instead I tried to look at the high-level things about software that I've slowly understood. www.youtube.com/watch?v=RJgD...

Broadly yes, but we do take a handful of people from other career stages. Video recordings are great to have, but expensive, and alas we lack the budget to do it now.

I feel fortunate, because I get to sit through all the talks myself -- I've learnt a _lot_ over the years!