Whenever you have a proposal like this that essentially laments that we don't have the nice shiny thing, it's quite useful to take a few step backs and ask "well, why don't we have it," and try to consider some of the problems with it. This paper is no exception--advocating for a return to a Smalltalk/LISP machine approach as opposed to Unix; why don't we have those things?
The facile answer is the "no true Scotsman"--we've never really had a true, whole-system approach to this, only approximations, and if only we had that true, whole-system approach, everyone would fall in love with it. I'm not persuaded. We were forced to use a Smalltalk environment for one of our classes, and the reaction was pretty universally negative. Not because it was a lamentably incomplete instantiation of a wonderful thing, but because if you screwed up--as anybody is wont to do--you would just absolutely and sometimes irreversibly hose the entire system. Imagine trying to poke at an error stack trace resulting in the only editor you could use to fix it breaking with the only means of recovery going back (outside of the all-encompassing environment, mind you) to an older version.
So I think that's the real reason these systems never took off: "everything works together" too often becomes "everything breaks together." Hotpatching code sounds nice, but it now means you get to deal with stuff like "oops, the global cache has both the old and new version stuffed in it and something else is hosed as a result." Replacing "sqrt" with "mysqrt" everywhere also implies the ability to replace "open" with "vfsopen" everywhere... only to accidentally map it to a VFS that has no files and now you can't open any files on your system from any application.
For me the problem has never been about outright breakage.
For IDEs, I have often observed: the whole is less than the sum of the parts. Trying to cram them all into one UI ends up removing a lot of capabilities, and it is always more difficult to add additional parts after the fact (since we should never assume all tools can be up-to-date with a changing world), compared to simply using the tools individually.
I found confort in Java and .NET ecosystems, it is not the whole package, but the closest we as industry apparently managed to get closer to Xerox PARC ideas.
> Imagine trying to poke at an error stack trace resulting in the only editor you could use to fix it breaking with the only means of recovery going back (outside of the all-encompassing environment, mind you) to an older version.
Imagine being able to go back to an older version, and then being able to re-play the log of actions you'd taken to just before you broke the editor.
The facile answer is the "no true Scotsman"--we've never really had a true, whole-system approach to this, only approximations, and if only we had that true, whole-system approach, everyone would fall in love with it. I'm not persuaded. We were forced to use a Smalltalk environment for one of our classes, and the reaction was pretty universally negative. Not because it was a lamentably incomplete instantiation of a wonderful thing, but because if you screwed up--as anybody is wont to do--you would just absolutely and sometimes irreversibly hose the entire system. Imagine trying to poke at an error stack trace resulting in the only editor you could use to fix it breaking with the only means of recovery going back (outside of the all-encompassing environment, mind you) to an older version.
So I think that's the real reason these systems never took off: "everything works together" too often becomes "everything breaks together." Hotpatching code sounds nice, but it now means you get to deal with stuff like "oops, the global cache has both the old and new version stuffed in it and something else is hosed as a result." Replacing "sqrt" with "mysqrt" everywhere also implies the ability to replace "open" with "vfsopen" everywhere... only to accidentally map it to a VFS that has no files and now you can't open any files on your system from any application.