I like a lot of what Joel writes, but I profoundly disagree with him on this, and I'm not alone in my dislike of accidental complexity which, which I think is now an order of magnitude greater than essential complexity. So there is a "silver bullet". It just needs someone to bite it.
The author of the article recognizes there's a problem, but is less clear on how to go about solving it. A clue is in this article by Erik Naggum: http://naggum.no/erik/complexity.html
Dan Ingalls once wrote: "Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one." What he meant is we should migrate the functionality of the operating system into the programming language. This is possible if there's a REPL or something similar, so no need for the shell or command line. The language should be image-based, so no need for a file system. So, a bit like Squeak, or a Lisp with a structure editor.
There's still a gap between the processor and the language, which should be eliminated by making the processor run the language directly. This was done in Burroughs mainframes and Lisp machines.
Further up the "stack", software such as word processors and web browsers are at present written entirely separately but have much in common and could share much of their code.
Thanks for the link to Erik's essay - it was a great read.
I like the idea of an image based system, eliminating the need for the filesystem itself. I think the 'filesystem' and 'executable-process' ideas are so prevalent that they frame our thinking, and any new OSes tend to adopt these right away. But more interesting and powerful systems might emerge if we find a new pattern of operation and composition. Are you aware of any image based full stack systems that are in active development?
Android is one such system. Each app gets its own image (called Bundle) where it can store it's state. OS manages those state bundles to offer multitasking on memory-constrained devices and persist app state across reboots.
Android has a file system. It's a operating system (a Linux variant). I'm suggesting that neither a file system nor an operating system is necessary, or even desirable. Just run an interactive programming language continuously on the bare metal, with its image periodically backed up to secondary storage.
The author of the article recognizes there's a problem, but is less clear on how to go about solving it. A clue is in this article by Erik Naggum: http://naggum.no/erik/complexity.html
Dan Ingalls once wrote: "Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one." What he meant is we should migrate the functionality of the operating system into the programming language. This is possible if there's a REPL or something similar, so no need for the shell or command line. The language should be image-based, so no need for a file system. So, a bit like Squeak, or a Lisp with a structure editor.
There's still a gap between the processor and the language, which should be eliminated by making the processor run the language directly. This was done in Burroughs mainframes and Lisp machines.
Further up the "stack", software such as word processors and web browsers are at present written entirely separately but have much in common and could share much of their code.