That's not really the point of the topic though right, it's that in the UK I have the choice of a billion different ISPs, including (I think stupidly) three different fibre providers (I literally have two fibre connections to my house because I changed ISPs and they ran on different fibre networks), and in the US all I hear about is streamers complaining that they are all stuck with the same shitty ISP as there is no choice, in a country that supposedly champions choice.

Very odd, but perhaps more familiar to graphics programmers? I will say I'd probably call it a stall, which is exactly what the Vulkan docs call it moments later, so :shrug:

Yes you can buy games on GoG or Epic and play them on a steam deck or a steam machine. But it's juuuuust enough faff to be annoying enough, that you'd rather just get them on steam. I know people (and am a person) who have rebought games they already own so they are on steam, to make playing between steam deck and desktop more reliable.

It's the same with the steam controller. You _can_ use it with games outside of steam, but it's enough of a faff that you find yourself avoiding it.

It's incredibly effective, and why they are an effective monopoly in PC gaming.

Also, as a foreigner who lives over there, I think they are... sad? I'm surprised they got a positive reception from your coworkers. For me they are a backup and a failure to do something more interesting.

I don't know why they think this, but no? Perhaps it's badly expressed, but LLMs cut corners all the time. It's sort of their core fault really.

Anyway, I disagree with the core premise[1]. Re-writes are not cheap, because 1) code can be so bad it's unclear how to rewrite it[2], b) code can be so significant it's challenging to rewrite it (architectural choices, schemas, etc), and lastly if you're ever wanting to own your own code and not rent it from LLM companies, having it understandable by a human is still a goal worth working toward.

[1] To be fair, I think OP _might_ be talking about rewriting in the moment of the thing being built, but with some unspoken rule that once they think the change is good enough, then they are reviewing all the code? They don't make it clear..

[2] it's not even that hard. Write a test that exercises an end result and not the rule that causes that end result and 6 months later you've forgotten why the code is like that. I had to maintain a piece of software once where the primary form of tests were a bunch of snapshots of an end report being generated, based on some initial data input, mostly all unlabeled. The code was like "do this SQL query on table A and then take the second result". Why the second result? Your guess is as good as mine! I couldn't even work out why they were querying table A and not table B...

I think the issue is those repos being based on Arch though, not Arch itself.

In my experience using the AUR:

1. when you first install the package you can read the build script (and you should). These are in a very standard structure, and if the one you are reading is weird and complicated consider not installing it. No one is forcing you to. Almost every build script I read just downloads a build from a tagged github release.

2. when you get an upgrade you are shown the diff. For almost every AUR package I use this is literally just changing the $VERSION variable and the subsequent $HASH of the download. It is trivial to see if anything (in the AUR script) is happening that is sneaky.

It's really not that scary. And if it's considered scary, there are literally dozens of other linux distros (not to mention Windows or MacOS) you could be using instead.

Perhaps we are defining "job" differently? AI can, with much coaching, _perhaps_[1], do some _aspects_ of a programmer's job. But not all of it, or even the most important parts of it.

[1] given that we have spent the past many decades pointing out that developer productivity is possibly impossible to measure, or at least very hard; given "done" vs "done done"; given the history of "rock star" developers creating messes behind them, the difference between short and long term thinking and the external imperceptability of that difference; given all of that, we haven't really had enough time to form a valid opinion on what AI can do, in the long run.

I don't think it makes sense the assume the US considers any country its ally.

Maybe we run in different circles. Or did, anyway.

The reasons we rejected LoC and other measurements have not changed (broadly: code output isn't important, quality output is). AI has all the same problems people do. But for whatever reason we are throwing what we've learnt away. It's kind of embarrassing.

LLMs should be treated as untrusted. At all times.

The mind boggles at the attitudes that seem to have have led to LLMs being an excuse to throw any of the "science" in computer science we've managed to get into production out the window and go elbow deep into treating computers like mystical alchemy.

The next decade is going to be a bumpy ride.

And, fundamentally, in countries with employee rights, as an employee I do not give two shits about interest rates the company I work at borrows on. My philosophy on software design does not change. You can argue that the company might pick and choose who it makes redundant, and they might value people who produce "more product", but companies have always valued that visibility. It's your responsibility, if you care, to sell your actions in a commercial context. I don't think ZIRP changes that, and I have not personally noticed a change there.

Are they are all suddenly turning into zombies? No. Do they have any real idea what that is going to do to their body a few years down the line? Also no. Could it be catastrophic? Maybe!

I think about this when I think about how violently much of the industry has pivoted into AI being the primary generator of code in the last 6ish months. AI is the peptide, your codebase[2] is the body. Literally no one knows how maintainable this approach is, because there simply hasn't been enough time to find out. It could be fine. It could be a complete mess, with your entire engineering team falling asleep at the wheel, lulled into thinking they understand what is being built when they don't, completely impotent to fix or maintain it once the LLM is no longer able to.

[1] https://www.bbc.co.uk/news/articles/cdr268m5pxro

[2] Well, _their_ codebase. I've stopped doing it with my own personal codebases, unless I genuinely don't care about maintainability or longevity

I would say some of the indicators are a little odd.

Some of them are questionable in terms of capturing the spirit of the idea ("violent crime" being the same in the UK and the US is a surprising one to me for example. It's capturing serious assault per 100k, but is then not considering murder as violent crime. You have murder later, but maybe combine / group them?).

Some are confusing because they are not clear politically: everyone wants less violent crime, but I don't know your politics and so have no idea which direction you have weighted net migration and asylum/capita.

If you committed a row update but didn't update the index, a subsequent query using the not yet updated index would not find the updated row correctly.

It would also only work for certain types of indexes, you couldn't do it for uniqueness constraint for example.

I do agree that in theory you could have some extension to the index declaration that covers all that, but my worry there would be that it would be non obvious and a foot gun. Doing it the way described above makes that break in semantics clear.