I think you're right as far adults go -- adults are having fewer children because children are unaffordable.

Teens, OTOH, were almost never making a conscious decision to try to conceive children anyway -- if they got pregnant, that was an unintended side effect of having recreational sex. So if the teenage fertility rate is falling, the most likely explanation is that teens are either having less sex, or they are using contraception more effectively (or both). It's quite plausible that teens are simply spending less time in each others' physical proximity, and therefore having sex with each other less often.

Trump ordered the immediate surrender of Iran as well. What Trump commands and what Trump is competent to actually make happen are two vastly different things.

I mean, we could, but when the total expenses for building and running a solar farm are less than just the ongoing cost of buying more coal for an existing coal plant (never mind the maintenance or environmental remediation costs), that's almost literally lighting money on fire. It takes a pretty dedicated idealogue to hold out against the capitalist temptation of making more money solely to show the libs who's boss, and anyone who does so is likely to find themselves replaced by someone else who can "better maximize shareholder value". Hence the shift; even Trump can't stop an idea whose time has come.

Read your .sig

Maybe I don't read the Zeitgeist as well as I should, but AFAICT anything AI-related is seen as extremely uncool these days (at least, outside of certain tech-topian circles). So if Visa thinks "Adopting AI means people will think we're cool", I suspect they are in for a surprise.

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.

What a funny thing to say about something that is literally all text. Match up the code itself with the commit message and the ticket that caused it to happen - we work in the most documented business there is.

If you don't force/write good commit messages then you get what you deserve.

If you don't force/use good issue tracking then you get what you deserve.

In general, AI now composes my commit messages. Then I delete 2/3 of it. Sometimes I'll touch it up a bit. So it is helping our process...

For every line of code in our repo I know who wrote it, when they wrote it, what they said about writing it, and why they started to write it in the first place. If you don't know those things then you (or your organization) are doing it wrong.

Making games isn't actually that easy? I've been doing it for 25 years, and making a game that's good that people enjoy requires, in no small part, that you yourself enjoy playing games, and that you understand what fun is.

That's a good insight - we're essentially talking about art. There's no real indication that AI can do the actually creative part. But I wonder if a union can either? Art is about allowing inspiration to hit somebody like lightning and allow it to rise to the top. Unions are about making rules for everything to enforce fairness, and I wonder if that will be the most creative environment. Of course top-down corporations struggle with it too especially as they get bigger.

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).