LeCompteSftware

That's kind of the point of my comment - software developers couldn't release on NEC without excluding IBM customers etc etc. They were stuck with 1.44MB because that was the only thing guaranteed to work. There was a human management problem around agreeing on a specification; drive manufacturers and software companies simply had conflicting incentives, so the market was a mess.

In retrospect I think the only reason Zip was able to become the undisputed market leader in high-capacity disks is that CD-ROM fully took over commercial software distribution.

Lots of us are having fun identifying our choice for missing family :)

One I might suggest is scripting languages, defined loosely by programming tools which dispatch high-level commands to act on data pipelines: sed, AWK, the sh family, Perl, PowerShell, Python and R as honorary members. In practice I might say SQL belongs here instead of under Prolog, but in theory of course SQL is like Prolog. Bourne shell might be the best representative, even if it's not the oldest.

AWK et al share characteristics from ALGOL and APL, but I feel they are very much their own thing. PowerShell is quite unique among modern languages.

This is just wrong, you're being too didactic. Idris specifically lets you implement nontotal functions in the same way that Rust lets you write memory-unsafe code. The idea is you isolate it to the part of the program with effects (including the main loop), which the compiler can't verify anyway, and leave the total formally verified stuff to the business logic. Anything that's marked as total is proven safe, so you only need to worry about a few ugly bits; just like unsafe Rust.

Idris absolutely is a general-purpose functional language in the ML family. It is Haskell, but boosted with dependent types.

Lean is definitely a dependently typed ML-family language like Agda and Idris, so "ML" has it covered. And the long-term goal of Lean certainly is not "execution is only secondary"; Microsoft is clearly interested in writing real software with it: https://lean-lang.org/functional_programming_in_lean/Program...

OTOH if you really want to emphasize "intended to express proofs" then surely Prolog has that covered, so Lean can be seen as half ML, half Prolog. From this view, the Curry-Howard correspondence is just an implementation detail about choosing a particular computational approach to logic.

The real question is why were 1.44mb 3 1/2" floppy drives used for so long when they were totally obsolete by 1990. I would love to read a more coherent and unified history; my understanding is that there were tons of competing higher-capacity 3 1/2" drives between ~1985 and 1995, but software developers were stuck releasing on 1.44mb because that was the only format which worked reliably across manufacturers. By the time Zip drive came out, software was distributed on CD and higher-capacity floppies were really only used for (geographically) local data transfer.

Wikipedia says there was a serious attempt to standardize a 20mb floppy in 1990 which fell apart: https://en.wikipedia.org/wiki/Floppy_disk#High-capacity It's really not the case that Zip made some great leap forward; 15 years of technology's steady march didn't fully trickle down to consumer hardware because of compatibility issues between competing manufacturers.

Just FYI, this section at the end about R6RS Scheme is a little confused: https://fset.common-lisp.dev/Modern-CL/Top_html/Scheme-_0028...

   Strings are immutable [in Scheme]. Functional point update operations are not provided, presumably out of time complexity concerns, but string-append and substring are provided, and there are functions to convert to and from lists of characters; I guess the idea is that fine-grained string construction will be done using lists and then converted. Amusingly, there’s string-copy, though it’s hard to see why one would ever use it.

Strings are actually mutable in R6RS. See https://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_s... - there is an imperative update-in-place function which mutates the argument. So of course string-copy really is useful, you might want to mutate a string and keep an unaltered copy. And the intent of string->list is to automatically let your list-processing code become string-processing code. It is way too strong to say "Functional point update operations are not provided, presumably out of time complexity concerns" - R6RS actively encourages functional operations on strings by calling string->list first, even though that's O(n) overhead.

The overall point you are making seems clearly correct: R6RS Scheme does not provide any "mostly functional" datatypes beyond basic s-expressions, so it would take a lot of work to develop Clojure/FSet-style tools. But it's strange to so badly misstate what strings in Scheme are like.

This is a frustrating response to my comment. I am aware that symbiosis is universal. That's not what I'm talking about. I am talking about the specific and highly unusual behavior of crawling inside of a much larger animal's mouth and trusting it not to eat you. Cleaner fish are highly intelligent[1] and it appears that this intelligence is necessary for their niche:

- picking a good location for a cleaning station requires long-term planning and real strategic judgment;

- deciding which hosts to accept is a complex skill requiring some sort of rudimentary theory of mind + long-term development of social ties;

- like crows, cleaner fish are jerks who constantly try to screw each other over, so there is something of a cognition arms race.

I will add that the wrasse family of cleaner fish use rocks to smash open shellfish (i.e. they are tool-users), and they have very complex group strategies for raising their young. In fact I'm not convinced that wrasse evolved to be cleaner fish at all: they are natural scavengers and scum-suckers, perhaps cleaning stations are a form of cultural technology.

I would be extremely surprised if any of this was true for cone ants. I suspect that is more hard-wired, perhaps a local subspecies stumbled into a genetic fluke, and as you say due to game theory it is a local optimum this population has settled on. If this behavior were common like it is in vertebrates, we probably would have seen it earlier. But who knows? 20 years ago I would have thought "fish have a form of culture" is too ridiculous an idea to consider.

[1] Seriously: https://journals.library.columbia.edu/index.php/cusj/blog/vi... https://www.nature.com/articles/s41598-025-25837-0

This is very cool, and quite surprising. Cleaner fish are thought to be among the most intelligent fish because of the complexity and danger of their feeding strategy: it takes careful planning and quick thinking. But they aren't tied to any particular species of host or general tactic; naively I imagine cleaner fish are more versatile and adaptable than cone ants.

It would be interesting to learn if this occurs with other species of ants. I suppose until now nobody thought to look.

>> In-situ resource utilization (ISRU) plant development for a sustainable lunar outpost

The image is clearly Mars.

"Yes they crashed into a wall and all died, whereas you steered around it, but you must acknowledge that they crashed twice as quickly as you didn't crash. If you were driving their car, you would have just slowed them down."

People should have read to the end of "Building a C compiler with a team of parallel Claudes"[1]:

  The resulting compiler has nearly reached the limits of Opus [4.6]’s abilities. I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality.

"tried (hard!)" is very ominous. I wonder how Mythos would fare. Presumably it would get further, maybe much further. But I strongly doubt the "frequently broke existing functionality" problem was solved. Eventually humans have to understand the most difficult parts of the code. Good luck with that!

[1] https://www.anthropic.com/engineering/building-c-compiler

It seems a little silly to put 71 years of private-and-public-sector infrastructure development alongside something highly targeted like the Manhattan Project. It might make more sense to compare the Manhattan Project to the first transcontinental railroad, as a similar targeted but enormously ambitious project amounting to a major technical milestone.

Likewise I don't think it makes sense to compare post-ChatGPT hyperscaler data center construction with all 19th-century US railroad construction. Why not include the already considerable infrastructure of pre-AI AWS/Azure? The relevant economic change isn't "AI," it's having oodles of fast compute available online and a market demanding more of it. OTOH comparing these data centers to the Manhattan Project is wrong in the opposite direction: we should really be comparing a specific headline-grabber like Stargate.

This categorization is just a confusing mishmash. The real conclusion to draw here is that we tend to spend more on long-term and broadly-defined things than we do on specific projects with specific deadlines. Indeed.

Did you miss this part?

   But he was doing this for education, not for work.

That's why he should spend 6 hours on it, and not give up and run to the gym. That's like saying "I shouldn't spend an hour at the gym this week, lifting weights is hard and I want to watch TV. I'll just get my forklift to lift the weights for me!"

IMO the more salient point is that bugs requiring multiple weeks of human work aren't going away! Claude has actually not been trained on, say, a mystifying and still poorly-explained Java concurrency bug I experienced in 2012, which cost a customer $150,000. Now in 2026 we have language-side tooling that mitigates that bug and Claude can actually help a lot with the rewrite. But we certainly don't have language tooling around the mysterious (but now perfectly well-explained) bug I experienced in 2017 around daylight saving's time and power industry peak/off-peak hours. I guess I haven't asked, but I can almost guarantee Claude would be no help there whatsoever.

Just so many confusing things go wrong in real-world software, and it is asinine to think that Mythos finding a ton of convoluted memory errors in legacy native code means we've solved debugging. People should pay more attention to the conclusion of "Claude builds a C compiler" - eventually it wasn't able to make further progress, the code was too convoluted and the AI wasn't smart enough. What if that happens at your company in 2027, and all the devs are too atrophied to solve the problem themselves?

I don't think we're "doomed" like some anti-AI folks. But I think a lot of companies - potentially even Anthropic! - are going to collapse very quickly under LLM-assisted technical debt.

I believe the point (which you seem to tacitly agree with) is that a young dev's time is much better spent reading and writing code "the old-fashioned way" vs chasing the new SOTA in AI-assisted development. A competent dev can basically master agentic development in a few months. But it takes years to become competent.

This is ominous and very depressing given what we've recently learned / reconfirmed about LLMs sapping our ability to persist through difficult problems:

> There were 2 or 3 bugs that stumped me, and after 20 min or so of debugging I asked Claude for some advice. But most of the debugging was by hand!

Twenty whole minutes. Us old-timers (I am 39) are chortling.

I am not trying to knock the author specifically. But he was doing this for education, not for work. He should have spent more like 6 hours before desperately reaching for the LLM. I imagine after 1 hour he would have figured it out on his own.

"LLMs couldn't do any damage with hallucinated citations"

If you're saying stuff like this with a straight face then you are clearly not a scientist and you don't know what you're talking about. In 2021 there were maybe 10 papers with fictional citations. Even the publication mills at least linked to other junk papers. Now there are hundreds of thousands of papers with dishonest and useless bibliographies. This is because LLMs are an unbeatable force multiplier for dishonest and useless scientific work.

I am sure some legitimate academics are getting real use out of them. I am also sure that the net effect of LLMs on science is enormously negative, and it will take decades to fix the mess.

This doesn't even slightly answer my question. The incredibly frustrating thing about the AI discussion is the refusal to consider actual evidence because of shifting targets. In 2026 there is evidence that 2024 LLMs did enormous damage to scientific research in 2025: hallucinated citations, hallucinated experiements, an onslaught of unreadable prose, etc etc. But we can't talk about that, can we? That's old hat, everybody knows 2024 LLMs were stupid and useless. Instead we have to discuss our vibes about 2026 LLMs, and maybe in 2028 we'll be able to tell whether or not our vibes were correct.

"that's actually pretty useful contribution to science"

Why? Serious question. Surely the only people using the LLM for such specific STEM domains are the exact same people who are "chasing grants instead of researching." Certainly I can see how training an LLM on this stuff can help automate the process of grant-chasing, and maybe OpenAI can expand their homework cheating business to graduate schools. But I do not see how this stuff helps honest researchers, except a bit around the margins (e.g. perhaps Claude isn't so good at the Perl used in bioinformatics, that's a use case justifying some RLHF from a PhD).

It really seems like the main utility of this stuff is getting a higher score on Humanity's Last Exam and showing the customers/investors that actually Opus 4.9 is 2% smarter than GPT 5.5. Separately there are AlphaProof/etc-style LLMs for solving real research problems in math and CS, but those techniques don't even work for theoretical physics, let alone biology.

That shouldn't be viewed in isolation. A major root cause is essentially overproduction of academics downstream from the Cold War, and obviously the private sector is not to blame for that.

But you can't ignore how much modern Big Tech has sucked away from academia compared to the tech companies of the Cold War era. Microsoft Research and Google Research have some impressive folks, but even combined they are a scientific pittance compared to the might of Bell Labs, and there is far more interference from the business side. This despite the fact that the executives of those companies are vastly wealthier than anyone from Bell Labs in the 20th century, even adjusting for inflation.

And of course it's not just the executives: every 7-figure Google software engineer should get a >$100k pay cut, and that money goes to a STEM PhD to pursue nonprofit research at Google Labs. Believe it or not, $100k is still pretty competitive for a young PhD mathematician (similar to assistant professor at a selective state school). Even if it's chump change for a guy who fine tunes AdSense.