The linked paper also gives a summary of the issues with using Ada -- tl;dr: We like the language, but no one's learning it and no one's supporting it.
Which is kind of sad, because the very thing that makes Ada useful -- stability and maturity -- is the thing that's killing it.
Seems like there is pretty good support now from AdaCore.
The main thrust of this appears to be that "fresh college graduates are not putting Ada on their resumes."
I suppose these guys from Lockheed know what they're talking about... but to me, the idea that you pick a language based on whether it's being taught in universities is just asinine. If your engineers are not smart enough to learn a new language, they're not smart enough to go near any kind of software that has anything to do with an airplane.
Even more troubling, this suggests that engineers are treated as "cogs" that can't be re-trained and just become obsolete as soon as the "main language they learned in school" (the top places don't focus down on one language too much IMO) becomes obsolete.
Agreed, it's troubling. Ada is easier to learn than C++.
I'm wondering if the whole thing was orchestrated by C++ static analysis tool vendors. Or some set of byzantine keyword-centric recruiting requirements make it difficult to hire someone who is capable of learning Ada.
Have you ever actually used Ada? The standards document is incredibly clear and well-organized, to the extent that most Ada programmers use it for reference.
I have -- and I'm not busting on Ada, quite the contrary -- I'm pointing out that many of the rules in the C++ document would not be necessary were they coding in Ada.
(I'm sure they use static analysis tools for C++ that enforce some of these rules, so I'll defer to someone who is more current in that world)
AV Rule 6
Each deviation from a “shall” rule shall be documented in the file that contains the deviation. Deviations from this rule shall not be allowed, AV Rule 5 [specifying the process to deviate from a "shall" rule] notwithstanding.
Even if the original comment were advocating that, which it's not, it remains to be demonstrated that the number and seriousness of the bugs would actually get worse if the software were developed using a different kind of language.
>Even if the original comment were advocating that, which it's not, it remains to be demonstrated that the number and seriousness of the bugs would actually get worse if the software were developed using a different kind of language.
No, it has _already_ been demonstrated, not only for the language, but for the process.
What remains to be done is for people saying that it remains to be demonstrated to educate themselves with the relevant papers.
Hell yes,
Although seriously, I wonder what the end difference in bugs and software related (hardware) crashes would be? And also the cost of development and speed with which updates could be released. (No i'm not really advocating it, but it would be fun).
The problem arose not from the time change, but from the change in longitude
I don't think you can blame the time handling for that one! Although you are right in the broader sense that is really difficult to write code that handles times and dates correctly, and you generally shouldn't write you're own. I'd imagine the guys writing this stuff are pretty good though and can probably handle it.
The rules seem quite reasonable and less strict than what I had expected. The libraries section mentions "Only DO-178B Level A certifiable" libraries. Are any common open source libraries among those and is there a list available somewhere? Another HN thread mentioned that there are certified C++ standard libraries but I couldn't find any vendor of such.
I suspect not, but I'd be happy to hear otherwise. Certification is as much about process and traceability as it is about the code itself. Open source naturally tends to give visibility into the development process, but there's usually no business driver to spend the money on certification. Think multiple thousands of dollars per line of code.
You cannot certify libraries.[1] The best you can do is to provide a certification kit which consists of tests to be run in the target environment and appropriate documentation/traceability.
However, as the GP notes the libraries must merely be "certifiable": You can do all the certification work yourself as long as it is possible with the libraries in question. Having access to the source code and the lack of non-determinism are two big requirements that come to mind.
[1] In fact you cannot even certify software only entire systems.
Referring to [1]: So, if I would try to sell libraries targeted at avionics there is no way for me to get certification for that specific library? Is there a way to guarantee "certifiability"?
I don't believe they are just sitting out there like open source. I believe you will have to purchase this libraries. Just like you. However, the problem boils down to the fact that you will be developing on custom hardware, thus the libraries will probably not be reusable. Basically you have to prove that all lines of code are part of the requirements, no dead code. You will also have to prove that all code fails in a fail safe manner. I.e. the plane won't crash
Level A cert is for flight critical systems, I.e. flight controls.
Well, I'll tell you why, in case you are the person in charge and can do something about it.
If I click through the links at the top of the page, there is no real indication of "staleness or non-staleness," until you get to Open-DO Conference, which has material from 2010 presented as if it's new. Then, the next link ("Forge") has "Latest News" from 2010.
Update: I did not even realize there was a blog, because you linked me to open-do.org/about/ instead of just open-do.org. There is no evident link to see a blog, so the assumption of the website designers must be (perhaps unfortunately) that you always enter directly through open-do.org. It turns out that clicking the title graphic will take you there as well, but someone who is initially linked to the "about" page would never think to click on that.
By the way, thanks again. I'm not interested in the details of the sub-projects right now, but now that I have found the blog, my personal valuation of the site has gone from "encouraging" to "actually quite useful." I've already found interesting/relevant reading on the blog.
The buses used on aircraft are interesting. ARINC 429 is used for commercial aircraft. MIL-STD-1553 is used for military aircraft. STANAG3838 is the EU equivalent.
Wikipedia suggests a logic analyser for development. That's handy, but you'd be best starting with good continuity buzzing; I've seen some of the cables being made and it's a bit of a bodge.
Most likely using 1553. Since its a military aircraft and most DoD equipment for aircraft use 1553. AIRNC 429 is typically isninly user when trying to integrate a COTS equipment. However 1553 wouldn't be ideal for exchanging large amoints of data.... more like "status" and switching. Its highly deterministic regarding timing of messages.
Interesting that this document is stored on Bjarne Stroustrup's (creator of C++) web site at AT&T Labs. I wonder whether he had any part in writing it?
> ...I consider it a pretty good set of rules for safety critical and performance critical code. If you do embedded systems programming, you should consider it. Caveat: I had a hand in the formulation of these rules, so you could consider me biased...
> Dear C++ programmers: follow this! (with exceptions accordingly)
These strict C++ programming guidelines apply only to embedded and safety critical programming and the programs that are being written work under a very restricted runtime environment and with a less than state of the art compiler.
So if you're a regular application programmer working with C++, feel free to ignore most of these rules. Modern compilers and runtimes will work nicely with most of the stuff forbidden in these guidelines.
There are some limitations there relating to embedded systems (for example, they explicitly forbid the use of atoi because obviously you want to be sure of no undefined behavior while flying at Mach 2 at 20kft)
For example, section 3 are very general good rules
Av Rule 84/85 are very relevant as well (just an example)
It's very easy to exaggerate when using C++ and hence some limits are needed.
My brother works for Lockheed writing technical manuals. He is the guy who writes those things. I mean, I can't even read them without runing away screaming.
He studied IT, but never got a job in it. I keep bugging him to get a job coding, but he thinks he can't.
Anyone got a job coding for someone who writes those amazingly complex manuals?
Just to add to what was already said, the doc said for enumerator values - which are indeed lower case in the example. Not a blanket statement for all variables.
AV Rule 69 says to use `const` by default on member functions. Yet in some examples (e.g. AV Rule 122 in Appendix A) they don't use the `const` keyword when they can.
