The perfect is the enemy of the good. - Voltaire, possibly.
Sure, the OS could have been rewritten from the ground up to behave according to this guy's Laws Of Sane Personal Computing. But that would probably take ten years. (And maybe it's nearly time for an effort like that to start, given that the original Macintosh System lasted about sixteen years before everything was thrown out to start OSX.) Add it in bit by bit and you can work out the actual implementation details, growing it from both the top and the bottom of the OS. And the end user gets the benefit of an "imperfect" but functional implementation of these ideas for the, I dunno, fifteen years it'll take you to core out the old OS while it's still running, and dump in some new chunks that do the Right Thing all the way down at the deepest levels.
I wish this guy the best of luck in building a functional OS from scratch that does the Right Thing. It sounds like it could be pretty cool, albiet kind of mind-twisting to get used to using. (It feels alien to modern computing paradigms in pretty much the same way a lot of Jef Raskin's visions were, IMHO.) But in the meantime, I'll be over here using the half-baked version Apple implemented.
I think this is simply wrong. Certainly, abstractions tend to leak, but the loper-os guy thinks that you can't create a usable system unless you extend lisp-like concepts all the way down to the CPU designs. He never seems to acknowledge that technologies like virtualization actually work to create independent environments.
This is because they don't.
Environments can be independent in the information-security sense (what you and others confuse with full conceptual independence) without being independent in the propagation-of-brokenness sense. Easy example: your power supply.
Give me, say, a Common Lisp (rather low bar!) environment which is entirely uninfluenced by the brokenness of x86. [1] Then we'll talk about independence of layers.
When the last idiot talking about static languages being "inherently efficient" has vanished, then we'll talk about independence of layers.
--
[1] For instance: the fact that you need threads at all. On a dataflow architecture, threads and their attendant idiocies - locking, race conditions, etc. are forgotten like a bad dream.
When he says "Even if you ... plug all abstraction leaks, the lowest-level concepts on which a system is built will ... limit the heights to which its high-level “payload” can rise." I'm reminded of the part in a Deepness in the Sky when Vinge muses on the nature of the increasingly complex and layered systems which control the ram ships and how no one was ever able to completely refactor the mess.
And that was where I stopped taking him seriously. This author sounds to me as though he is complaining that his free pony is dappled, not purebred. His arguments all sound, ironically, correct - in a skin-deep way. He discounts, with wincing ease, the evolutionary steps that are the necessary prerequisites to getting to where we are now. Reading this is like listening to Stephen Wolfram talking about cellular automata - it is a shining, glittering, many-tined work of an absolute crank.
Where under your car's hood have you stuffed your horses?
I have to say, something like this wouldn't be very useful to me. I want more control over how my mass storage is used: I frequently run systems with mostly-full partitions, and something like that sounds like a very quick way to push my system over the edge into constant failure mode.
I have to say, something like this wouldn't be very useful to me. I want more control over how my mass storage is used: I frequently run systems with mostly-full partitions, and something like that sounds like a very quick way to push my system over the edge into constant failure mode.
Before you say my way is objectively wrong, ask yourself whether you really want to dictate hard rules about workflow to someone you don't even know.
