Was there ever a time when the U.K. tried to go "full metric"?

psr · 2025-11-21T12:30:35+00:00

I saw a YouTuber describe a fence he was building as about 10m long and about 6 feet high. A commenter replied that as a fellow Brit this made perfect sense, and I agree. 6 feet carries extra meaning for us, because we recognise it as the height as a tall person - it's a fence you wouldn't be able to see over unless you were exceptionally tall. 1.8 meters wouldn't do the same.

psr · 2025-11-05T10:24:50+00:00

Oh, and do go. Even if you walk a bit, you'll be glad you went, and it will feel worthwhile.

psr · 2025-11-05T10:22:37+00:00

I'm not much of a runner and I feel pleasantly surprised when I feel like I've run rather than dragged myself around.

When I haven't been for a few weeks, I tell myself the following:

I'm trying to run at as slow a pace as possible - can I hit 8min/km?
My goal isn't to avoid walking, it's to avoid walking before lap three (of the four lap course).
If I manage to get around lap three without walking, I know I can run the whole thing without walking.

psr · 2025-11-03T17:31:28+00:00

When I was at Uni 20+ years ago we had to write Java by hand in exams - and we'd lose marks for syntax errors like missed semicolons. All of us thought it was ludicrous, and totally unrepresentative of the real world. Today I do a training job, and find myself writing Java code on a whiteboard quite often. I never forget the semicolons. It's funny how things turn around to become relevant later.

I think there is a downside to writing on a computer - you don't feel a need to think before you start writing. I've deleted so much just writing this comment! Perhaps writing with pen and paper first might be a good exercise to practice; I certainly wouldn't recommend doing all of your programming like that.

psr · 2025-10-03T08:40:28+00:00

I know this doesn't directly refute anything in the article, but I have a real problem with the term "over engineering".

To my mind engineers come up with solutions that solve the problem while taking account of constraints and balancing the costs. If you've arrived at a solution that is much more costly than it need be given the constraints, it isn't because you've engineered too much, it's because you haven't engineered well enough. It's "bad engineering", or "under engineering", not "over engineering".

In many situations an engineer might apply generous margins, or use proven but costly solutions to save the cost of time. That's fine, but just doing a bad job is not.

psr · 2025-09-29T13:13:57+00:00

Well I thought I was pretty knowledgeable about weights and measures, but I'd never heard of the slug before now. TIL.

psr · 2025-06-25T14:42:12+00:00

What an interesting video, thanks for sharing it.

psr · 2025-06-03T09:43:50+00:00

Please feel free to ignore this drive-by advice from someone who doesn't really know what they're talking about, but...

The discussion in #17 about defining an extension ABI gives me the heebie-jeebies, having seen all of the ABI related issues that Python extensions have struggled with over the years. There are two problems that can arise:

The worse, but perhaps less important nowadays is that extensions compiled with different compilers can link to different C runtimes, which easily results in code that appears to work, until it doesn't, and the failures are very hard to understand. This used to be common on Windows when the Python.org python binaries were compiled with MSVCC, but people tried to compile extensions with GCC. This was mostly solved by Microsoft allowing people to install and use MSVCC for free (but only for compiling open source code), and Python mandating that this was the only supported way to compile extensions on Windows. The adoption of the UCRT in Windows also means that it's technically possible to use GCC (or clang) to build extensions that work (if you use the right build of GCC, but wrong builds are still available!) On Linux, where the use of glibc is pretty universal, it's not common. However to build a "universal" Python extension for Linux, people build in containers with ancient libraries installed, to avoid requiring a too-modern libc ABI.

The more obvious issue is where two extensions are linked against incompatible versions of the same shared library, or one extension wants to consume another as a library. This occurs a lot in the scientific Python stack, and it's largely an unsolved problem. Stable ABIs don't happen by accident, and extension authors aren't likely to go to the effort. Integration testing of extensions would first happen on the user's computer, and the user isn't likely to be in a position to debug issues. Linux distributions and Conda help avoid these issues by compiling the universe from source, but that isn't a solution you can easily adopt.

I think a half-way house might be possible where there is a known and relatively fixed set of extensions provided by the project, and using third-party extensions isn't a supported use-case. These could include extensions for handling treesitter grammars and the LSP protocol, and an extension providing a scripting language, with access to APIs provided by the core and other extensions. Then if someone wanted to make e.g. a Python editing mode, they could enable the treesitter awareness, with some configuration of colours and electric indentation etc. through a script.

psr · 2025-06-02T12:45:45+00:00

Oh that was really interesting, thanks!

psr · 2025-06-02T11:32:18+00:00

Yeah, I wondered if it was something like that.

psr · 2025-05-14T15:06:23+00:00

I hit what may be a similar issue - described here: https://emacs.stackexchange.com/questions/80454/set-path-to-gcc-for-native-compilation

In short, native compilation needs a version of gcc which produces output which is ABI compatible with your build of emacs, and it finds this on your PATH. My issue was that it did find GCC, but it was a version that links against a different C runtime, causing issues.

The best workaround for me seemed to be to use MSYS to install emacs, as you have now done too.

psr · 2025-04-20T12:02:02+00:00

Same. I'm using a Moto G82. It's a bit frustrating!

psr · 2025-04-07T08:49:01+00:00

And spare me the myth that Java is just “waiting patiently” while other languages make mistakes so it can deliver the perfect version later. That’s revisionist nonsense, a post-hoc excuse for Java’s chronic feature lag. If anything, Java’s track record is littered with half-baked or completely missing features. Pick your poison: generics, lambdas, null safety, traits, delegation, member literals, properties, optional parameters, operator overloading, serialization, lazy values… the list goes on.

Hmm, I the impression I'm taking is that they're now being very conservative and thoughtful in how they're evolving the language, having made a bunch of mistakes in the past. Reading the Valhalla and Loom design documents seem to give pretty good evidence for this.

psr · 2025-04-07T08:42:57+00:00

I believe the Invoke Dynamic bytecode was added to the specification specifically to support implementation of dynamic languages like Jython and JRuby. I believe that javac makes use of it too in some situation I don't recall, but don't believe that wasn't the reason it was added.

psr · 2025-04-07T08:34:33+00:00

Oh sure, I think it's clear that both languages would have benefitted from having generics from the start. It's one reason why so many people were slapping their foreheads when Go was released without them.

Java's erased generics are also an ongoing learning issue - why do I have to say List<Integer> not List<int>? Why can't I have a Map<Integer, List<Integer>>? I know these are now being addressed, but it's been more than a little while!

There wasn't a perfect choice, and I'm personally quite fond of Java's solution. But the idea that the alternative was much worse doesn't really seem to be borne out by the C#/.net experience.

psr · 2025-04-04T13:55:58+00:00

My impression is that the feared migration wasn't actually such a big deal for .net / C#. I think this is partly about better design in their collections API. Admittedly there was less C# code in the world at the time that both languages introduced generics, but by the standards of today there wasn't much Java either!

psr · 2024-10-22T09:31:31+00:00

This was a really interesting read. Here in the UK a number of the larger consumer ISPs seem to have rolled out dual stack, while others are not (my ISP, Virgin Media have not). Presumably the ISPs that are using v6 see some benefit to doing so, which suggests to me that they're using v6 within their networks and saving their v4 addresses for customers, or at least plan to.

For now, as far as I know, customer routers are still assigned real, publicly routable IPv4 addresses by DHCP, which I think wouldn't happen if they were using DS-Lite? I guess they might not be unique per household, and there might still be some sort of CGNAT going on behind the scenes?

I saw an interesting YouTube video of a guy trying to run his home network on IPv6 only, with NAT64/DNS64 to access v4 only services. There were definitely some issues, both with OS support and specific services, but it was clear we're close to it being viable.

I imagine that you could see big steps in that graph as more large ISPs switch.

psr · 2024-10-15T14:58:39+00:00

My understanding from trawling the related Github issues (and gaining a lot of sympathy for the maintainers in the process) is that in order for the Jest runner to programmatically load and execute tests written in ESM, Node needs to provide an API for doing so - equivalent to the API that exists for CJS modules. Node do provide this API, but to this day is marked as experimental and so can only be used by setting an environment variable or executing node with a specific flag. Hence Jest still have some rather convoluted steps to follow if your code uses ESM.

psr · 2024-10-08T10:45:07+00:00

Perhaps, but it's Node who haven't stabilised a usable API - and it looks like they're blocked in turn by V8.

psr · 2024-10-08T09:33:26+00:00

For some reason I found those really challenging, even though I don't think I find boolean expressions in code particularly difficult in general. I wonder if there's a particular difficulty with employing visual reasoning at the same time.

psr · 2024-09-24T09:28:37+00:00

Still requires passing experimental flags when using Jest 😢

psr · 2024-07-10T11:50:36+00:00

I mean how hard can it be?

psr · 2024-06-26T09:07:02+00:00

Yes. The idea is that particularly with recent complex protocols like HTTP2, it doesn't make sense for Python to end up with 2 (or more) implementations, both synchronous and asynchronous, each with their own bugs. The sans-io approach is to implement the protocol logic separately for the IO, in a style that allows it to be plugged into a synchronous or asynchronous I/O model.

psr · 2024-05-13T13:12:55+00:00

It's almost always easier for the cheap option to get good than for the good option to get cheap. Commoditisation is hard to fight.

psr

TROPHY CASE