I tend to agree (although this article feels a bit like it's "picking on" some whimsical projects that aren't making grand claims ... or are they?) A term I li

I tend to agree (although this article feels a bit like it's "picking on" some whimsical projects that aren't making grand claims ... or are they?) A term I like to use for this phenonemon is "Inner Platform Effect". https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect The prime example is that in the 90's, Java thought they were going to make Windows irrelevant (a pile of poorly debugged device drivers or something like that). But now Java is just Windows/Unix process. Same with all these "alternative computing stacks" -- in the end they will almost certainly be just Unix processes. The only situation I can think of where they wouldn't be is a revolution in hardware like the IBM PC producing MS-DOS, etc. And even not then, because we already had the mobile revolution starting ~15 years ago, and both platforms are based on Unix (iOS/Android). ---- I do think people should carefully consider whether they want to create an "inner platform" or make the platforms we ACTUALLY USE better. That is the purpose of https://www.oilshell.org/ https://www.oilshell.org/. Evolving working systems is harder than creating clean slates. So clean slates are fun for that reason: you get to play God without much consequence. Sometimes clean slates introduce new ideas, and that's the best case. But a common pattern is that they are better along certain dimensions (the "pet peeves" of their creator -- small size, etc.), but they are WORSE than their predecessors along all the other dimensions! So that is the logic of Oil being compatible and painstakingly cleaning up bash -- to not be worse than the state of the art along any dimension! I've experimented writing a clean slate shell in the past, but there are surprising number of tradeoffs, and a surprising number of things that Unix shell got right. ----- But Oil can ALSO be viewed as a clean slate, which is sometimes hard to understand. https://www.oilshell.org/release/latest/doc/oil-language-tour.html https://www.oilshell.org/release/latest/doc/oil-language-tou... I just drafted this doc, and surprisingly little breaks even in the non compatible mode: What Breaks When You Upgrade to Oil https://www.oilshell.org/preview/doc/upgrade-breakage.html https://www.oilshell.org/preview/doc/upgrade-breakage.html So I would like to see more systems take a DUAL view -- compatible, but also envision the ideal end state, and not just pile on hacks (e.g. Linux cgroups and Docker are a prime example of this.) You will learn the wisdom of the system that way, and the work will be more impactful. For example, it forced me to put into words what Unix (and the web) got right: https://www.oilshell.org/blog/2022/03/backlog-arch.html https://www.oilshell.org/blog/2022/03/backlog-arch.html