physicsguy

On 1) though, they're an inch deep and a mile wide.

It used to be more common in the U.K. but it’s pretty rare now. Stews and braising were the traditional way to cook it as older ones are kind of tough.

I think they do but only when it's applied to learn some specific spatial task.

We can see for e.g. that frontier models have got really good at CAD sorts of tasks recently. That suggests benchmaxxing RL to a degree but it does mean they've suddenly got quite good at forming simple geometries in a step by step way.

This misses the point entirely of why C is as it is.

It’s quirky because when you had kilobytes of RAM, storing the length of the string was memory you couldn’t afford. Arrays decaying into pointers similarly meant carrying a single pointer around rather than a fat struct. Magic integers for return codes were used because they’d fit into a single register. Compilers didn’t have the processing power or memory to track complex borrow rules or static analysis. They were slow even as they were! Old processor architectures were way more diverse and fragmented than now - and even 30 years ago endianness wasn’t a settled thing.

Things weren’t quirky because people “wanted” them to be, they were quirky because everything was way more constrained. Rust came into a way more rationalised environment and it’s a great language of course but the operating environment is so totally different it’s hard to compare.

Colin Furze - and at least for part of it he didn’t! The council sent him an enforcement notice and he had to get it done retrospectively

Very good!

> I did a PhD in magnetic materials

There are two of us on here!

I was going to say that people encounter ferrimagnets more commonly than pure ferromagnets I think, since as we both know pure ferromagnets tend not to have very high anisotropy.

I got Claude to design me a shed the other day. I asked it to make the door hinged in the CAD software I am using, and it did, but parts of the door weren't attached to each other so some were left floating when I set the door open.

People were definitely asking for it.

Oh this is great, it was one of my biggest bugbears about Go since you almost always have to link C/C++ code to get the appropriate performance.

The one negative I'd say is that often autovectorisation is 'good enough' and this doesn't really tackle that gap.

We're still quite some way off that in the UK. Copper lines still working though due to shut down by next year I think. Lots of older people with no internet left in the lurch with phone lines with that of course.

> I live in a European country, where the phone company hasn't bothered to come remove the old unused copper phone lines in the last 5 years. Thousands of dollars worth of cables running past my house alone, and no one has bothered to go strip it in the night and sell it

Isn't that because they're still flat out on rolling fibre out? There's not that many telecoms engineers and if they spend tons of time removing the old, that slows down the new.

I ran into the exact same wall when doing some SIMD + OpenMP optimisations.

Me: "Parallelise this loop without changing the results."

AI: "I can't do that, because of floating point accumulation."

Me: "So spin out a temporary fixed-length array, accumulate into that thread-locally, and then do an ordered summation of that at the end."

AI: "Oh, you're right!"

It's a fantastic tool for automating the implementation grind, but you still have to hand-feed it the strategy. I guess it will get there at some point.

That is true if you're using them as chatbots but for something behind a product it's largely OK as long as it meets the requirements.

I'm finding that executives at work are generating AI slop and sending it at each other and teams that are then meant to digest it, without any critical thought. Often these are sloppy and contain broad mistakes that aren't relevant to our company's setup.