The timelines matter as well: They were working on EUV at Zeiss (who make the lensing/mirroring systems) already in 2005. That's about 20 years of development.
Slight problem with that if you would like to live in a functioning, thriving democracy: democracy in the sense of "one person, one vote" requires or at least greatly benefits from a broadly educated population. It's not sufficient, but very likely necessary.
You're right -- the theoretical particle physicists at my faculty were using Mathematica very heavily when I was still in academia and maintained a dedicated compute cluster for it.
They really did not appreciate the debugging experience, but maybe that's improved in 15 years. :)
I realize you're making a general point about space/IO ratios and the below is orthogonal, no contradiction.
It's actually a lot less user-facing per disk IO capacity that you will be able to "sell" in a large distributed storage system. There's constant maintenance churn to keep data available:
- local hardware failure
- planned larger scale maintenance
- transient, unplanned larger scale failures
(etc)
In general, you can fall back to using reconstruction from the erasure codes for serving during degradation. But that's a) enormously expensive in IO and CPU and b) you carry higher availability and/or durability risk because you lost redundancy.
Additionally, it may make sense to rebalance where data lives for optimal read throughput (and other performance reasons).
So in practice, there's constant rebalancing going on in a sophisticated distributed storage system that takes a good chunk of your HDD IOPS.
This + garbage collection also makes tape really unattractive for all but very static archives.
I think Chips and Cheese is more like a fine replacement for realworldtech.com sans the toxic and highly educational and entertaining forums. Anandtech was much more accessible to the general tech public, but also more commercial and thus hit and miss on the content (no judgement intended, gotta eat).
Any remaining reasonable use cases would be sufficiently corner-casey that that the first order approximation is "if you want it to behave like a database, no, you do not want MyISAM".
This being said, at least some years ago, a use case I saw that held SOME water then was generating MyISAM tables offline, importing them as-is into a running MySQL (or taking an instance offline and bringing it back up) and then serving from it read-only. At least at the time, this provided better RO performance than InnoDB. I wouldn't be surprised if that was still true. Please don't do that at home!
Also, I think until the previous-to-most-recent release, some internal tables were still MyISAM, causing MySQL overall to have some very rare cases of not being crash safe. Again, I think that's since been resolved in 5.8(?).