I don't use Gimp as a 3D modeling software or a digital audio workstation. I use it to add text to a family photo. The primary storage medium is jpeg. I don't want or need anything else.

The real issues with Gimp start when you try to work with selections, transforms, cuts, crops and so on. Photoshop muscle memory doesn't transfer and it is so incredibly clunky.

There are many many more but start with the app having the overbearing assumption that it thinks you want save to its file format rather than make an ad hoc edit.

I too got fed up with the prose of Opus in particular, and tried going back. Unfortunately, the previous models were less able to hack it. The prose was better but progress was worse.

It wasn't just conversation and comments. Some of the function names were wild. Like it instead of something like "isSolidWall(x)" it would write something like "weightyNotEphemeral(x)" or something - that's not quite it, but it really did embed overwrought antithesis into the identifier instead of a straightforward positive predicate.

Sentences that orbit a point, then jump to it like it's a revealed insight.

Unnecessarily abstract phraseology. Constantly using inanimate nouns as the subjects in sentences in order to unlock variety in verb choice, especially when it helps construct a sentence where the real action can 'land' like a surprise at the end.

It is definitely more capable, and yes, I've found it can make unwarranted decisions, but actually I've found Fable worse for that, particularly if it's off in a subagent somewhere out of sight.

And comments are out of control. I have a subsystem in my hobby app that I wrote over a couple of weekends with Opus + Fable. After ~30 or so commits it apparently started instructing subagents to copy the "existing verbose comment style of the codebase" - a verbose style it initiated. A review of the code showed it was approaching 3:1 comments to code ratio. I spent a day's worth of tokens (5x) rephrasing and eliminating comments.

We're all well aware of the money supply, M1 / M2 / M3, velocity of money, etc. It's important for money to not get tight when the economy slows down, and it's important to tighten up the amount of money when the velocity increases again. But this is neither deficit spending nor printing money without backing!

Inflation is can come from a social psychological phenomenon around expectations. If the cost of living goes up in a surprising way, you feel the pinch. You want more money. Maybe your employer gives you a raise, and raises prices to compensate, reasoning that other things are also going up in price. The risk is this creates a self-propagating loop (which in turn does to a degree depend on accommodating institutions that don't restrict monetary supply).

You can trigger inflation through loose monetary policy, sure, and you can dampen the cycle by restricting the supply of money, and that's been the main function of independent central banks for most of the latter 20th and 21st century.

But inflation is literally just increase in the cost of living. It's a symptom, not a disease. It admits multiple explanations.

It can be caused by deficit spending. It can also be caused by supply shocks. For example, if you restrict building new housing, the price of housing will increase, both rents and house prices. If you tariff imports, a basket including those goods will rise in price to the degree those imports are not substituable. If you start a war in the Middle East, oil prices will rise, and increased energy costs can feed into lots of different things, raising prices.

The major differences with C++:

    * objects are references not values, cutting out all the copy constructor,
      assignment operator, destruction on out of scope etc.
    * objects are zero-initialized after allocation and before constructors run
    * constructors are run from most derived to least derived
    * calling Free method checks if Self is nil
    * this + zero init means that you can call '.Free' on all the objects you 
      reference in the destructor without checking if they're nil first, 
      handling partial construction

Delphi did native exceptions much better IMO.

Your mileage may vary, but I sleep better with my own projects not having any node_modules in their build tree.

Of course there's an issue if the data in the database is contractually restricted and you don't have a zero retention endpoint for inference, but the former usually comes with the budget to fund the latter.