Block rewards have no connection to transaction volume or economic activity, the protocol is designed such that bitcoin supply increases at a predictable (and diminishing) rate. Bitcoin is deflationary by design, which is one of the major issues that stopped it from becoming anything other than a speculative store of value.

Another way to interpret dark matter is that we can observe something using several different ways, but all those ways use gravity. When trying to observe this something using electromagnetism, we see nothing. It doesn't seem so crazy then to hypothesize that this something only interacts with gravity, and not electromagnetism.

To me write scaling is the main current advantage of KV and document DBs. They can generally do schema evolution fairly easily, but nowadays so can many SQL DBs, with semi-structured column types. Also, you need to keep in mind that KV and document DBs are (mostly) non-relational. The more relational your data, the less likely you are to actually benefit from using those DBs over a relational, SQL DB.

I have a phd in economics. Most researchers in that field have never even heard of any of those tools. Maybe LaTeX, but few actually use it. I was one of very few people in my department using Zotero to manage my bibliography, most did that manually.

Money is never backed by nothing, or it's worthless. It may not be backed by anything physical, but it's always backed by some form of trust. National currencies are backed by trust in the corresponding government and institutions.

I've had that experience plenty of times with actual people... LLMs don't "think" like people do, that much is pretty obvious. But I'm not at all sure whether what they do can be called "thinking" or not.

So I tried to test this (my intuition being that indexes wouldn't change much, at best you could just do an index scan instead of a seq scan), and I couldn't understand the plans I was getting, until I realized that the query in the blog post has a small error:

> AND c1.category_id = c1.category_id

should really be

> AND p.category_id = c1.category_id

otherwise we're doing a cross-product on the category. Probably doesn't really change much, but still a bit of an oopsie. Anyway, even with the right join condition an index only reduces execution time by about 20% in my tests, through an index scan.

Makes you wonder how many cases there are out there of optimizations that feel almost second nature in one domain, but have never been applied to other domains because no one thought of it.

> - When asked to fix a bug, it confidently declares victory without actually having fixed the bug.

You need to give it ways to validate its work. A junior dev will also give you code that doesn't compile or should have fixed a bug but doesn't if they don't actually compile the code and test that the bug is truly fixed.