Comment by jchw
5 years ago
You can’t just build a better developer when a single mistake is end game. Even if you do everything right you can still run into problems.
The reason for that is because large projects can’t have only one developer. As soon as you have multiple developers you have a problem. What happens when two developers begin working on the same base commit. Developer A makes a change to remove a contractual behavior that is not relied upon. Developer B makes a change that relies on this contractual behavior. Both changes are correct on their own, could very well pass code review simultaneously, and then both merge without conflicts. And then your last life line is whatever guarantees you have via static analysis, etc. (notably, this could still fail in a memory safe language if there aren’t any safe guards for this particular logic bug. Nothing is a panacea. Having more tools to write safer code, though, can at least help prevent some of these cases.)
That’s assuming everyone is perfect and has unlimited time to write perfectly sound code always. And it still fails.
You point to Rust but nobody said it had to be Rust. Still, just because Rust is not a panacea does not mean it has no value. On the contrary, while there has been decades to hone practices for secure C, Rust is a relative newcomer and obviously shows a ton of promise. It and other new memory safe languages are very likely to take a bite out of C usages where security is important. You can embrace this or deny it... but if you think it’s not happening, you should definitely take a look at the writing on the wall, because it’s certainly there. On the other hand, there are also other approaches. I believe seL4 is doing C code with proofs of correct operation. (Admittedly, I do not fully understand what guarantees this gives you and how, but it sounds promising based on descriptions. There could still be bugs in the proofs, but it certainly raises the bar.)
> You can’t just build a better developer when a single mistake is end game.
Why not?
Doctors got better with more training and better strategies towards medicine, and that's a game where a single mistake really is "end game".
Doctors benefit from better tools and processes too, but this is all wildly beside the point, because my point was not that we can’t build a better programmer, it’s that we can’t just build a better programmer, for the reason that I then went on to outline.
You bring up a great point, though. Historically, C is often not trusted for software where people’s lives are on the line. Thus bringing up doctors is a great example of how building a better programmer is not good enough. There’s an entire class of “safety critical” programming practices and standards and it was common to prefer a language like Ada that made more bugs and logic errors into compiler errors.
> it’s that we can’t just build a better programmer, for the reason that I then went on to outline.
Apologies for missing your point. I thought you meant by this:
> The reason for that is because large projects can’t have only one developer.
... that you meant we would have to change more things in our business and software cultures rather than just making programmers smart (something I could agree with), not that you believed this was some kind of truism.
I don’t believe this is true. Why are you convinced it is impossible to do “big” things without big teams of idiots?
> Historically, C is often not trusted for software where people’s lives are on the line. Thus bringing up doctors is a great example of how building a better programmer is not good enough.
I don’t see how one of these things has to do with the other. Can you explain the link?