36,301 karma · joined March 3, 2007
Data, compilers, software architecture
barry.j.kelly@gmail.com
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
It's not a memory safe language, but it does give you a bunch of idioms that, if you stick to them, you don't feel nearly as much pain as C++.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.
I'm having a much better time with jj and a workspace per subagent than I was with git and worktrees.
It's still useful to have the CI gating on updating the master branch pointer, but you largely stop working with branches once you switch to jj.
- modelling the system rather than implementation (system status rather than many individual service statuses)
- supporting causal reasoning: the control flow on top means you can trace failure modes back, visually; software systems typically only model their own ontology, and you need to look somewhere else for the next abstraction down
- surface state first rather than time series; a pretty graph is nice to look at, but for actionability sometimes what you need is the flashing red light
- prioritize first-out indicator. In a complex system with lots of alerts, the most important diagnostic alert is often the first one - the rest are downstream and contribute to alert fatigue, despite them probably being more important business metrics
I know you say it's not production ready and not optimized yet, but in the same breath - in your comment here - you say it's already faster.
It's most obvious on the roads. Few non-commercial vehicles will limit your speed to the national maximum. Wouldn't a strict interpretation of your opinion imply speed governors?
At the same time, one should acknowledge that not all tasks are on the same level.