There's no rule you have to own QQQ and indeed most people don't. There are thousands of low cost ETFs that provide passive exposure to the market. If this new rule bothers you, be like most people and buy one of those instead of QQQ. Problem solved.

Like sure, let's improve our tax systems (as an aside, I would say there are many more efficient and progressive options than a wealth tax, but whatever), but I don't see how there is even a tangential link between that topic and the NDX rule change.

Before the printing press, very few people in Europe owned even a single book. But even a lower class, modern European might easily own several dozen books. Depending on how you account for this, you might conclude that the given lower class, modern person is among the richest people in Europe in 1400. Or you might not properly account for the wealth of a 1400 European noble and rank them as middle class by modern standards.

It's simpler with commodities like a bushel of wheat, but still complicated. Depending on what you are trying to explain, you can use different methods but there is not straightforward way to convert the cost of something in one time period to another time period.

And again, I'm not making a claim that the slow and steady tradeoff is best for all situations. Just that it is a great tradeoff for foundational platforms like a runtime. On a platform like postgresql or the JVM, the time from initial proposal to being released as a stable feature is generally years, and this pace I think has served those platforms well.

But I'm open to updating my priors. Do you think there are foundational platforms out there that iterate quickly and do a good job of it?

Speed code all your SaaS apps, but slow iteration speeds are better for a runtime because once you add something, you can basically never remove it. You can't iterate. You get literally one shot, and if you add a awkward or trappy API, everyone is now stuck with it forever. And what if this "must have" feature turns out to be kind of a dud, because everyone converged on a much more elegant solution a few years later? Congratulations, we now have to maintain this legacy feature forever and everyone has to migrate their codebase to some new solution.

Much better to let dependencies and competing platforms like bun or deno do all the innovating. Once everyone has tried and refined all the different ways of solving this particular problem, and all the kinks have been worked out, and all the different ways to structure the API have been tried, you can take just the best of the best ideas and add it into the runtime. It was late, but because of that it will be stable and not a train wreck.

But I know what you're thinking. "You can't do that. Just look at what happens to platforms that iterate slowly, like C or C++ or Java. They're toast." Oh wait, never mind, they're among the most popular platforms out there.

My issue with the observational studies is that basically everything is uncontrolled. Maybe the IDEs are causing less defects. Or maybe some problems are just harder and more defect prone than others. Maybe some teams are better managed or get clearer specifications and so on. Maybe some organizations are better at recording defects and can't be fairly compared with organizations that just report less. The studies don't ever reach the scale where you become confident these things wash out.

If they control the problem, most of those issues are eliminated (though not all, for example the experience and education of the participants still needs to be controlled), but now you are left wondering how well the findings transfer from the toy projects in the experiment into real life.

But finally, it's still not a perfect metric because not all defects are equal, right? What if some tool/process helped you reduce a large number of mostly cosmetic defects, but increases the occurrence of catastrophic defects?

re: LoC, there's some signal here, but it's such a noisy channel, I've never read a study that I thought put it to good use. Happy to have my mind changed if you have a link to one.

I personally like and use tests, formal verification, and so on. But the evidence for these methods are weak.

edit: To be clear, I am not ragging on the researchers. I think it's just kind of an inherently messy field with pretty much endless variables to control for and not a lot of good quantifiable metrics to rely on.

What’s the evidence for anything software engineers use? Tests, type checkers, syntax highlighting, IDEs, code review, pair programming, and so on.

In my experience, evidence for the efficacy of software engineering practices falls into two categories:

- the intuitions of developers, based in their experiences.

- scientific studies, which are unconvincing. Some are unconvincing because they attempt to measure the productivity of working software engineers, which is difficult; you have to rely on qualitative measures like manager evaluations or quantitative but meaningless measures like LOC or tickets closed. Others are unconvincing because they instead measure the practice against some well defined task (like a coding puzzle) that is totally unlike actual software engineering.

Evidence for this LLM pattern is the same. Some developers have an intuition it works better.

It’s a news site with a lot of auto-playing video. If you like that kind of content, great. If not, there’s lots of other websites with different mixes of content. I subscribe to the economist which has few videos and they never auto play.

But that’s a question of taste. 5mb of JavaScript and hundreds of tracking assets is not.

But at least in terms of the headline metric of bandwidth, it's somewhat less horrifying. With my ad-blocker off, Firefox showed 44.47mb transferred. Of that 36.30mb was mp4 videos. These videos were journalistic in nature (they were not ads).

So, yes in general, this is like the Hindenburg of web pages. But I still think it's worth noting that 80% of that headline bandwidth is videos, which is just part of the site's content. One could argue that it is too video heavy, but that's an editorial issue, not an engineering issue.

IME, the tools are largely interchangeable. They are all slightly different, but the basics of prompting and the jaggedness of the frontier is more or less the same across all of them.

Switching from codex to claude code is orders of magnitude simpler than switching from c# to java or emacs to vim.

The site does describe it as a "programming language," which feels like a novel use of the term to me. The borders around a term like "programming language" are inherently fuzzy, but something like "code generation tool" better describes CodeSpeak IMHO.

I see all the time on the Internet (and even IRL once) people make claims like, "oh, carbon taxes will just increase CO2 output, you know like in that Israeli daycare study." Drives me nuts.

Are fines the best possible solution to this particularly traffic problem? I have no idea. I'm not an expert in this area. But I am highly confident that whatever relation it has to the Haifa daycare study is so incredibly tenuous that it is not worth mentioning.

They fined parents (IIRC) ~$3 per late pickup. Rerun the study with a $300 fine and let’s see how it pans out. It’s an interesting finding, but that then people take it to mean that fines don’t work (no matter their size) is insane.

If the argument is that it was a stupid business decision, but he had other motives (clout, etc…), sure whatever.

Peer reviewed does not mean the findings of the paper are established fact or scientific consensus. It does not mean that the findings have been replicated by other scientists. It does not mean that the paper relied on a robust methodology, is free of basic statistical errors, or even free of logical fallacies.

Some of these limitations are due to the limitations of peer review itself. Others are just side effects of the way science works (for example, some ideas start as small, unimpressive experiments that are reported on in papers, and the strength of the findings is gradually developed over time). Obviously sometimes the prestige (or lack thereof) of the journal the paper is in decreases (or increases) some of these issues.

Anyway, peer review is a very noisy channel (IMHO).

I think it’s also possible DoW didn’t care about the conditions but just wanted some pretext to punish Anthropic because Dario isn’t a Trump boot licker like the rest of the SV CEOs.

Depending on their budget and needs, a Neo, Air, or Pro.

Not sure it affects the outcome.