4 ms·
While I have personally never programed life critical stuff, I interacted closely (on the algorithmic side) with people who did. This was in the railroad indust
by alphaBetaGamma 17y ago
While I have personally never programed life critical stuff, I interacted closely (on the algorithmic side) with people who did. This was in the railroad industry.
They used a subset of C (no malloc...) and had a safety certified compiler. If you crash two trains because of a compiler bug at least you can pass the bunk. They did not use formal proof methods.
The documentation was massive, substantially longer than the code, to the extent that doing the actual implementation from the documentation seemed relatively trivial. Writing and analyzing the documentation on the other hand... I had the impression that writing documentation to that level of detail must have taken substantially longer than implementing it directly in code. And this was probably a good thing as it forced people to think more about every details.
Once a system was written it had to be certified. Any changes, no matter how trivial, meant you had to go through the whole certification process again: slow, painful and expensive.
- gcv 17y agoDoesn't the documentation have to then become as rigorous as code --- effectively a high-level language in its own right? So writing the documentation becomes, well, just like writing a program without testing it as you go, without benefit of tests or (if desired) static type checking. If so, then the development process turns the programmer into a kind of human compiler: translating the specs into a dialect of C for the safety-certified compiler.
- spitfire 17y agoActually the formal document languages have type checking and consistency analysis systems/tools. Tools like Alloy[1] allow you to write your documentation/definition and check its consistency. These languages are always limited so you don't get into Gödel incompleteness problems. 1. http://alloy.mit.edu/alloy4/ http://alloy.mit.edu/alloy4/