If the only goal is producing electricity at the current minimum price per kWh, then you have a good point.

OTOH if you also have a long-term goal of figuring out how to effectively design and build fusion reactors, then it's worthwhile to build them as best you can even if wind is currently more cost-effective.

As for why you might have such a long-term goal, I can think of several reasons:

1. Future fusion reactor designs might be much more economical to build and run, once enough hands-on experience has been gathered to make them so
2. Fusion reactors could be used in situations where wind power isn't available (e.g. space exploration)

Certainly the Secret Service would love to have an automatic head's-up on the true identity of anyone walking into the room. Not that I would expect this implementation to be reliable enough actually to be used that way, but someday one will be.

If I was deliberately trying to cause a nation-wide backlash against data centers, I'm not sure what I'd be doing differently from what the AI companies are currently doing.

Has nobody told them that people don't like having their lives disrupted, particularly when they don't see any compensating benefit, or even a convincing reason for having any of it? If they were to ease off the gas pedal just a bit, they could probably do a boil-the-frog and get a larger number of smaller/less-obtrusive data centers built over a longer time period, and without the voter revolts and strict legislation that are likely to hobble them now.

Objective C's syntax is objectively terrible; it mixes Smalltalk syntax with C syntax, confusing everyone. Its implicit heap usage makes it unusable for real-time programming (e.g. even Apple had to fall back to C to implement CoreAudio), and ARC is only a partial substitute for RAII.

Apple was right to switch over to Swift.

That's true, but when it takes Joe Random Hacker 10 seconds to generate a plausible-looking pull-request, which requires Joe Project Maintainer to spend 30 minutes reviewing the code-changes in that request, and Joe Project Maintainer isn't getting paid for his time spent doing the review, you've got all the ingredients for a distributed-denial-of-service attack on your project's maintainers. Perhaps AI code-reviewers can restore the balance, but I don't know how many project maintainers would trust their codebase's integrity to them (yet).

If they left them in place they might be used to collect data, which might in turn be used to show that climate change is a real problem. We can't have that, it gets in the way of maximizing oil companies's profits.

It's certainly possible to translate COBOL source into another computer language of your choice, although I'm not sure LLMs are the best tool for that job. An LLM might be able to give you more readable post-translation source code, but traditional machine translation would give you post-translation source code that works correctly, which is probably more important.

Another way to phrase that would be, "This is why C code is bad, because C programmers are expected to understand the rules about how to not leak memory, but there is no mechanism to enforce that requirement".

... and to their credit, eventually some of them do figure it out, and after that they (mostly) write good C code that doesn't leak. However, that doesn't change the fact that at any given moment there are millions of unseasoned C programmers out there who haven't reached that point yet, and who are nevertheless writing leaky code which gets put into production and causes trouble; and new C programmers appear every day. It's the Eternal September problem, applied to memory management.

So either (a) we ban C programmers from pushing to production until they've had at least 5 years of experience, or (b) we find some means to flag their errors at build-time, or (c) we live with the status quo messiness indefinitely. Linux is going with Rust as their mechanism for implementing plan (b).

If you have access to a God-tier LLM that you can rely on to find every bug, I think that could work.

However, I don't think anyone in the Linux community is ready to trust LLMs to that extent just yet. Not only are they quite fallible, they are also non-deterministic -- so if you ask your favorite LLM to find the bugs in the code, and it doesn't find any, and then you feed it the exact same prompt again, it might find some on its second attempt. So how do you know when to stop re-asking?

LLMs are currently constituted are very useful for finding bugs, but not so useful for guaranteeing that no bugs remain.

You know what improves code quality? Process improvements.

You know what doesn't improve code quality? Telling people that they suck. It's pointless and immature.

They might get a better responsie by requesting $4.99/month to remove the Meta AI slop from their Facebook interface.