6 ms·

"Even if a company has a few brilliant C programmers on staff, they won't be able to find all the issues the mediocre programmers produce." Also, I am very sce

"Even if a company has a few brilliant C programmers on staff, they won't be able to find all the issues the mediocre programmers produce." Also, I am very sceptical, that even brilliant C programmers won't have a bad day, lack of sleep or distracted by personal problems - to avoid misstakes. And about ADA, have you experience with it? What could be the reason, it is not used on a broader base? I assume also lack of libaries, etc.? I mean, there are millions of free and open C and C++ libaries around for allmost any usecase, I assume this is not the case with ADA? edit: about ADA https://www.electronicdesign.com/technologies/iot/article/21801203/comparing-ada-and-c https://www.electronicdesign.com/technologies/iot/article/21... is a good comparison of C and Ada, I found. Basically with ADA, you develope much slower (and performance is usually lower). But if you want reliability, it does sound good.

carlmr 6y ago
I have only hobbyist experience with ADA. It didn't seem nearly as hard as a lot of people said it was, and I was intrigued about in which ways it's safer than C. My best guess is that people are unfamiliar with ADA, unwilling to learn, and most of all believe that hiring will turn into a problem if they switch to ADA. Also they bring up the brilliant programmer theory. The hiring problem seems superficially compelling. There are indeed fewer ADA programmers out there, which of course is a chicken and egg problem if companies are not trying to adopt it. Now the fourth argument often follows the third argument. My problem with it is that most of the programmers I've worked with that I'd describe as brilliant are the first ones to tell you that we should use a safer language, because they know even they make mistakes. And a lot of the brilliant programmers wouldn't have trouble picking up ADA or learning something new. So my answer would be that if you truly have brilliant programmers, you don't need to worry about hiring. If you don't have those brilliant programmers you really can't afford staying with C because you will have huge costs from debugging and being sued for the bugs you didn't find.
MaxBarraclough 6y ago
> I assume also lack of libaries, etc.? I think that's a part of it. Few GUI toolkits can easily be used from Ada, for instance. Ada has excellent support for interfacing with C code, but making decent bindings is never trivial. I think lack of hype might be part of it too. Ada is seen as a stodgy and boring language good for writing autopilot software, whereas Rust and Zig are seen as new and exciting general-purpose programming languages. I'm not saying Rust and Zig bring nothing new to the table, of course, as they both do, but in terms of safety and programming with an emphasis on correctness, Ada has a lot to offer.
MaxBarraclough 6y ago
Sorry to double reply but I see I missed some of your points: > Basically with ADA, you develope much slower (and performance is usually lower) Ada deliberately emphasises readability over writeability. It might take a bit longer to do initial development work in Ada than in C, although it's likely that you'll encounter fewer bugs, so Ada might win out even here. Subsequent maintenance is likely to be cheaper/easier. I believe comparison studies have borne this out, although I'm not certain how trustworthy they are. As for performance: with runtime checks disabled, Ada should perform about the same as C/C++, as its abstractions don't tend to have runtime costs, it's just pretty plain imperative code. Ada isn't typically used with garbage collection, for instance. Like C++, you have the option of using the language's OOP features. With runtime checks enabled, you'll pay some runtime performance cost (let's say very roughly 15%, to simply make up a number out of nowhere). C and C++ don't give you the option of enabling as many runtime checks as Ada does, due to the free-form way arrays work, for instance. gcc and clang both give you the option of enabling runtime checks for certain kinds of errors, such as dereferencing NULL, but plenty of other kinds of error won't be caught. > But if you want reliability, it does sound good. Ada has some traction in the critical-systems space. The Boeing 777 flies on Ada, for instance. Of course, C and C++ are also both used for safety-critical software.
- hutzlibu 6y ago
  you just missed the "edit" in my edit ;) Thanks for more information.
  - MaxBarraclough 6y ago
    So I did. Glad it was of interest.
Veserv 6y ago
A process that can not survive a single programmer having a bad day is not a high reliability process. That problem is trivially easy to "solve" in any number of ways. 1. You can have multiple people whose job is to fully understand that code and review it. 2. You can have independent 3rd party reviewers whose job is fully understand the code and review it. 3. You can have adversarial reviewers from your competitors review the code with veto power over your code if they discover and can prove there is a defect. 4. You can have a requirements doc that traces to the code and a corresponding test to exercise that property. 5. You can verify that everybody understands the source by reading the compiled output to verify that it correctly traces to the expected source constructs. 6. You can have multiple people develop independent systems with the same functionality to run in parallel to crosscheck results with each other. 7. You can have those systems developed in isolation from each other so that they share no code or ideas giving even greater independence. 8. You can run these systems on the same and different hardware in parallel to provide even more independence and crosschecking. Every single one of these raises the bar from a single programmer having a bad day to requiring multiple people independently failing on the same code which is multiplicatively less likely. Every single one of these is something that is actually done for high criticality avionics software. Any "high-reliability" process that seriously considers a single programmer having a bad day as a material unsolved risk is made by complete amateurs. This does not mean high criticality avionics software is perfect, it just means that the concerns are more about actually hard problems such as how to prevent errors where a dozen brilliant programmers cross-checking each other will be unable to prevent the problem without the process. To put the difference in reliability between these systems into perspective, a "high-reliability" commercial system like AWS only promises 99.99% uptime in their standard SLA. In contrast, the 737 MAX, which most people consider an absolute deathtrap and evidence of the terrible quality of avionics code, had one failure per ~200,000 flights or 99.999% per-flight reliability (10x the reliability if we compare number-of-flights to seconds-of-uptime). If we were to consider all high-criticality avionics software, avionics software has not been implicated in any crash for the last 10 years except for the 737-MAX, so at ~10,000,000 flights per year for a total of ~100,000,000 that means avionics software has 99.999998% per-flight reliability or 5,000x the reliability if we compare number-of-flights to seconds-of-uptime.
- 6y ago

carlmr 6y ago

I have only hobbyist experience with ADA. It didn't seem nearly as hard as a lot of people said it was, and I was intrigued about in which ways it's safer than C. My best guess is that people are unfamiliar with ADA, unwilling to learn, and most of all believe that hiring will turn into a problem if they switch to ADA. Also they bring up the brilliant programmer theory. The hiring problem seems superficially compelling. There are indeed fewer ADA programmers out there, which of course is a chicken and egg problem if companies are not trying to adopt it. Now the fourth argument often follows the third argument. My problem with it is that most of the programmers I've worked with that I'd describe as brilliant are the first ones to tell you that we should use a safer language, because they know even they make mistakes. And a lot of the brilliant programmers wouldn't have trouble picking up ADA or learning something new. So my answer would be that if you truly have brilliant programmers, you don't need to worry about hiring. If you don't have those brilliant programmers you really can't afford staying with C because you will have huge costs from debugging and being sued for the bugs you didn't find.

MaxBarraclough 6y ago

> I assume also lack of libaries, etc.? I think that's a part of it. Few GUI toolkits can easily be used from Ada, for instance. Ada has excellent support for interfacing with C code, but making decent bindings is never trivial. I think lack of hype might be part of it too. Ada is seen as a stodgy and boring language good for writing autopilot software, whereas Rust and Zig are seen as new and exciting general-purpose programming languages. I'm not saying Rust and Zig bring nothing new to the table, of course, as they both do, but in terms of safety and programming with an emphasis on correctness, Ada has a lot to offer.

MaxBarraclough 6y ago

Sorry to double reply but I see I missed some of your points: > Basically with ADA, you develope much slower (and performance is usually lower) Ada deliberately emphasises readability over writeability. It might take a bit longer to do initial development work in Ada than in C, although it's likely that you'll encounter fewer bugs, so Ada might win out even here. Subsequent maintenance is likely to be cheaper/easier. I believe comparison studies have borne this out, although I'm not certain how trustworthy they are. As for performance: with runtime checks disabled, Ada should perform about the same as C/C++, as its abstractions don't tend to have runtime costs, it's just pretty plain imperative code. Ada isn't typically used with garbage collection, for instance. Like C++, you have the option of using the language's OOP features. With runtime checks enabled, you'll pay some runtime performance cost (let's say very roughly 15%, to simply make up a number out of nowhere). C and C++ don't give you the option of enabling as many runtime checks as Ada does, due to the free-form way arrays work, for instance. gcc and clang both give you the option of enabling runtime checks for certain kinds of errors, such as dereferencing NULL, but plenty of other kinds of error won't be caught. > But if you want reliability, it does sound good. Ada has some traction in the critical-systems space. The Boeing 777 flies on Ada, for instance. Of course, C and C++ are also both used for safety-critical software.

hutzlibu 6y ago
you just missed the "edit" in my edit ;) Thanks for more information.
- MaxBarraclough 6y ago
  So I did. Glad it was of interest.

Veserv 6y ago

A process that can not survive a single programmer having a bad day is not a high reliability process. That problem is trivially easy to "solve" in any number of ways. 1. You can have multiple people whose job is to fully understand that code and review it. 2. You can have independent 3rd party reviewers whose job is fully understand the code and review it. 3. You can have adversarial reviewers from your competitors review the code with veto power over your code if they discover and can prove there is a defect. 4. You can have a requirements doc that traces to the code and a corresponding test to exercise that property. 5. You can verify that everybody understands the source by reading the compiled output to verify that it correctly traces to the expected source constructs. 6. You can have multiple people develop independent systems with the same functionality to run in parallel to crosscheck results with each other. 7. You can have those systems developed in isolation from each other so that they share no code or ideas giving even greater independence. 8. You can run these systems on the same and different hardware in parallel to provide even more independence and crosschecking. Every single one of these raises the bar from a single programmer having a bad day to requiring multiple people independently failing on the same code which is multiplicatively less likely. Every single one of these is something that is actually done for high criticality avionics software. Any "high-reliability" process that seriously considers a single programmer having a bad day as a material unsolved risk is made by complete amateurs. This does not mean high criticality avionics software is perfect, it just means that the concerns are more about actually hard problems such as how to prevent errors where a dozen brilliant programmers cross-checking each other will be unable to prevent the problem without the process. To put the difference in reliability between these systems into perspective, a "high-reliability" commercial system like AWS only promises 99.99% uptime in their standard SLA. In contrast, the 737 MAX, which most people consider an absolute deathtrap and evidence of the terrible quality of avionics code, had one failure per ~200,000 flights or 99.999% per-flight reliability (10x the reliability if we compare number-of-flights to seconds-of-uptime). If we were to consider all high-criticality avionics software, avionics software has not been implicated in any crash for the last 10 years except for the 737-MAX, so at ~10,000,000 flights per year for a total of ~100,000,000 that means avionics software has 99.999998% per-flight reliability or 5,000x the reliability if we compare number-of-flights to seconds-of-uptime.

6y ago