James Gosling has a piece on fault containment. Its not a phrase I've used but I've advocated the principle for a long time now, for example using a programming language like C# instead of C or C++, or splitting large applications into multiple processes. He writes:
A lot of what motivated the tight memory model was me having wasted too much of my life tracking down weird exotic memory smashes, and vowing to never have to waste time on stuff like that again.
It puzzles me that I still see people wasting a lot of time on that type of bug-fixing, or observing it from a management point of view, but not making the connection that these problems are almost inevitable with a language like C++ and that development in C++ results in low productivity. Ok, I'm beginning to sound like a broken record but these days I often feel like I'm stuck on one.
Right now I'd like to see fault containment extend down into the implementation of drivers: I've wasted a lot of time recently - yet another hit on productivity - because a set of drivers written by a well known company occasionally bring down the whole OS. Maybe this will be possible one day. An EWeek article quotes researcher Larus on the Singularity project:
We've built an operating system written entirely in C#, all safe code except the kernel and a HAL [hardware abstraction layer] on top," Larus said. "The device drivers and everything else are written in a dialect of the safe form of C#.
I got that last quote from one of the comments to an interesting series of articles by John Siracusa - Avoiding Copland 2010 (plus part two and part three) - where he argues that the lack of a "managed" code programming environment will cause a crisis at some point in the next few years (via Ted Leung who also links to a post by Rainer Joswig; yes, I know that Lisp and Smalltalk had all these problems sorted years ago but I can't see how they will become mainstream; if only Apple had continued development of Dylan).