Kelly had a few other rules. One was that the engineers, the machinists, and the airframe must be physically close, preferably in the same building. That way, if a part wasn't working, the assembler, machinist, and designer could all get together at the airframe and figure out what to do about it. HP also had that approach to work in their glory days.
Another Kelly saying was "Kill problems, don't wound them". If some part is causing problems, don't make one that has fewer problems, redesign it so the problem goes away completely.
The "kill problems, don't wound them" idea reminds me of the idea in programming to make invalid states unrepresentable. It's not always possible to redesign problems away entirely, but if it is possible, it is a good thing to do.
Absolutely. A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.
For example, the JSF C++ guidelines say not to use 'l' suffixes on numeric literals, because they look like a 1. D simply makes the 'l' suffix illegal, use 'L' instead.
A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.
Exactly. That's why I'm bothered by Rust being almost protected against memory errors, and Go being almost protected against race conditions. Even if you give up some performance, it's a big win to eliminate entire classes of errors.
(Still, both are way ahead of C/C++ in this area. So far, I don't think there's been a CERT advisory for a Go program. Rust is too new to be attacked yet.)
It has been (7) days since the last CERT security advisory for a buffer overflow in a C/C++ program.
A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.
Depends on what you want. Give me a powertool and I'll give a powerful result. Give me safety scissors and I'll take much longer, and the result will probably be inferior. And I can say with some certainty that both products will be roughly equal in terms of safety, because I pay careful attention to safety when designing and implementing systems. But the products will differ greatly in terms of feature set, extensibility, and robustness.
It's difficult to add safety without subtracting power.
Kelly had a few other rules. One was that the engineers, the machinists, and the airframe must be physically close, preferably in the same building. That way, if a part wasn't working, the assembler, machinist, and designer could all get together at the airframe and figure out what to do about it. HP also had that approach to work in their glory days.
Another Kelly saying was "Kill problems, don't wound them". If some part is causing problems, don't make one that has fewer problems, redesign it so the problem goes away completely.