5 ms·

No wonder this thing doesn't fly (as expected). In all seriousness, perhaps the choice of the language has affected the software release dates?

by amaks 12y ago

amaks 12y ago
I'm surprised folks are down voting my comment. See http://rt.com/usa/f35-jet-software-delay-233/ http://rt.com/usa/f35-jet-software-delay-233/ for example. And as the one who programmed in C++ for 20 years I think I know what I'm talking about.
- w0utert 12y ago
  You are being voted down because your comment was completely unsubstantiated. Maybe if you had thought about it a little longer you'd have figured put there aren't actually that many (any?) viable alternatives for C++ for the kind of systems programming you'll find in a fighter jet. Or, if you disagree, you could have offered some insight as to what these languages would be. If you can't have non-deterministic behavior such as GC, you can't waste gobs of heap or stack memory, you have to be able to interface with C libraries and embedded components, you need hard real-time guarantees, and your whole development stack needs to be stable and well supported, you end up with C or C++, it's that easy. You don't gamble by picking the hipster language du jour all the cool kids use to write websites or phone apps, but proven technology that (if used correctly) gives you reliable and predictable results, and will still be around and supported in 40 years time when these jets are still in service. Blaming the failure to deliver the f35 on time and within budget on C++ is really quite a cheap stab.
  - Jtsummers 12y ago
    C/C++ aren't the only languages that lack a GC (see Ada) or in which you can severely restrict the GC (see Rust, though it's not suitable for this sort of project yet). The OS that most of the software runs on (that is, not the software running on LRUs with their own embedded OS) offers the same APIs to Ada and C and C++. It was a choice to go with the non-Ada languages. Ada is hardly a hipster language, it's been around for 35 years and will likely be around the rest of this century (for better or for worse).
    - w0utert 12y ago
      Well, that may be true, but what advantages does Ada offer over C++? I understand it may be one of the (very few) workable alternatives for this kind of systems, but I can imagine has many disadvantages over C++. Where do you find enough developers with Ada expertise, for example? How current (up-to-date) are Ada toolchains? How many commercial vendors can provide and support Ada toolchains? Can you expect weird incompatibilities linking between internally developed Ada code, and externally provided C++ code? Questions like this are probably why the DoD decided to move away from Ada, not problems with the language itself. Almost nobody uses Ada for anything anymore, so sticking with it would have been a risk. I agree that it's not a hipster language, that qualification was supposed to languages like Go, Rust, JavaScript, etc. which are very popular right now, but completely unsuitable for writing the control software of a fighter jet.
      - Jtsummers 12y ago
        Well, that may be true, but what advantages does Ada offer over C++? http://extranet.eu.adacore.com/articles/Ada%20Cpp.pdf http://extranet.eu.adacore.com/articles/Ada%20Cpp.pdf I had a longer section here, but then came across this. Check out the section on the type system to get a clearer version of what I wanted to post. I really think that the type system alone is (for a lot of the embedded systems I've seen/worked on) a good enough reason to switch. The rest of the language is simple enough to learn in an afternoon if you're just wanting to replace C. I don't know how many bugs I've seen that were caused by everything being an int. Even using typedefs in C, they don't restrict the range of values or give significant compile/runtime guarantees when one type is stored into another and they both happen to be ints or chars or something. I understand it may be one of the (very few) workable alternatives for this kind of systems, but I can imagine has many disadvantages over C++. Where do you find enough developers with Ada expertise, for example? Perhaps the greatest problem for Ada, I don't know. There are some colleges that use Ada in introductory courses. There are others with strong ties to the defense/aerospace industry that happen to offer Ada courses as electives. The rest is going to be recruiting from curious individuals or companies that happened to recognize its value or that got stuck with a substantial Ada codebase from the 80s/90s. How current (up-to-date) are Ada toolchains? How many commercial vendors can provide and support Ada toolchains? Very, it's an actively developed language. Ada 2012 [1] is the most recent version, though given that I'm really encouraging this for embedded use you'd be using a subset of that. AdaCore is the primary developers of GNAT, which is current through Ada 2012. Green Hills and Wind River also support through Ada 2012. Can you expect weird incompatibilities linking between internally developed Ada code, and externally provided C++ code? Not sure, FFI is not something that would've been used in any of the embedded systems I'd have recommended using Ada for. The language reference does specify how calling to C/C++, Fortran and Cobol code should function or be exposed within an Ada implementation. See the above PDF, it speaks a bit about FFI with C. [1] http://www.ada-auth.org/standards/ada12.html http://www.ada-auth.org/standards/ada12.html ----------------- A couple years ago I could've probably written up a better response, I've all but given up on Ada in my workplace. ----------------- EDIT: I should probably also confess a bit of an infatuation with good type systems and formal verification tools/processes. I've seen what results when these are absent, I've quit jobs because these were absent and the culture prevented any improvements. I'm not working on safety critical systems anymore, but if I ever end up back in those projects I will insist on using the right tools/processes. I don't want to wake up one day, turn on the news and read about a crash or malfunction that was caused or should have been prevented by my systems. Poor processes and tools enable these failures, and we should have zero tolerance for them. We have certifications/licensing for engineers (mechanical, civil, aerospace, electrical, etc.). If they sign off on a system/design that fails catastrophically and the failure should have been detected (via models or industry standards or whatever), they are held liable. Software developers in the safety/critical systems space have too cavalier an attitude, we're too well insulated from the aftermath of our defects. That attitude may never be changed, but a change in tools/processes to ones that contain, minimize or eliminate large classes of failures is certainly worth the effort.
- Too 12y ago
  Not my downvote but to me there's no wonder you got downvoted. Why is it no wonder these things don't fly? Are the rules too strict? too loose? too broad? too stupid? or is it the choice of language? Your post provides no insight into your opinion at all and added no value for anyone else, quite the contrary.

No wonder this thing doesn't fly (as expected). In all seriousness, perhaps the choice of the language has affected the software release dates?

by amaks 12y ago

No wonder this thing doesn't fly (as expected). In all seriousness, perhaps the choice of the language has affected the software release dates?

amaks 12y ago

I'm surprised folks are down voting my comment. See http://rt.com/usa/f35-jet-software-delay-233/ http://rt.com/usa/f35-jet-software-delay-233/ for example. And as the one who programmed in C++ for 20 years I think I know what I'm talking about.

w0utert 12y ago
You are being voted down because your comment was completely unsubstantiated. Maybe if you had thought about it a little longer you'd have figured put there aren't actually that many (any?) viable alternatives for C++ for the kind of systems programming you'll find in a fighter jet. Or, if you disagree, you could have offered some insight as to what these languages would be. If you can't have non-deterministic behavior such as GC, you can't waste gobs of heap or stack memory, you have to be able to interface with C libraries and embedded components, you need hard real-time guarantees, and your whole development stack needs to be stable and well supported, you end up with C or C++, it's that easy. You don't gamble by picking the hipster language du jour all the cool kids use to write websites or phone apps, but proven technology that (if used correctly) gives you reliable and predictable results, and will still be around and supported in 40 years time when these jets are still in service. Blaming the failure to deliver the f35 on time and within budget on C++ is really quite a cheap stab.
- Jtsummers 12y ago
  C/C++ aren't the only languages that lack a GC (see Ada) or in which you can severely restrict the GC (see Rust, though it's not suitable for this sort of project yet). The OS that most of the software runs on (that is, not the software running on LRUs with their own embedded OS) offers the same APIs to Ada and C and C++. It was a choice to go with the non-Ada languages. Ada is hardly a hipster language, it's been around for 35 years and will likely be around the rest of this century (for better or for worse).
  - w0utert 12y ago
    Well, that may be true, but what advantages does Ada offer over C++? I understand it may be one of the (very few) workable alternatives for this kind of systems, but I can imagine has many disadvantages over C++. Where do you find enough developers with Ada expertise, for example? How current (up-to-date) are Ada toolchains? How many commercial vendors can provide and support Ada toolchains? Can you expect weird incompatibilities linking between internally developed Ada code, and externally provided C++ code? Questions like this are probably why the DoD decided to move away from Ada, not problems with the language itself. Almost nobody uses Ada for anything anymore, so sticking with it would have been a risk. I agree that it's not a hipster language, that qualification was supposed to languages like Go, Rust, JavaScript, etc. which are very popular right now, but completely unsuitable for writing the control software of a fighter jet.
    - Jtsummers 12y ago
      Well, that may be true, but what advantages does Ada offer over C++? http://extranet.eu.adacore.com/articles/Ada%20Cpp.pdf http://extranet.eu.adacore.com/articles/Ada%20Cpp.pdf I had a longer section here, but then came across this. Check out the section on the type system to get a clearer version of what I wanted to post. I really think that the type system alone is (for a lot of the embedded systems I've seen/worked on) a good enough reason to switch. The rest of the language is simple enough to learn in an afternoon if you're just wanting to replace C. I don't know how many bugs I've seen that were caused by everything being an int. Even using typedefs in C, they don't restrict the range of values or give significant compile/runtime guarantees when one type is stored into another and they both happen to be ints or chars or something. I understand it may be one of the (very few) workable alternatives for this kind of systems, but I can imagine has many disadvantages over C++. Where do you find enough developers with Ada expertise, for example? Perhaps the greatest problem for Ada, I don't know. There are some colleges that use Ada in introductory courses. There are others with strong ties to the defense/aerospace industry that happen to offer Ada courses as electives. The rest is going to be recruiting from curious individuals or companies that happened to recognize its value or that got stuck with a substantial Ada codebase from the 80s/90s. How current (up-to-date) are Ada toolchains? How many commercial vendors can provide and support Ada toolchains? Very, it's an actively developed language. Ada 2012 [1] is the most recent version, though given that I'm really encouraging this for embedded use you'd be using a subset of that. AdaCore is the primary developers of GNAT, which is current through Ada 2012. Green Hills and Wind River also support through Ada 2012. Can you expect weird incompatibilities linking between internally developed Ada code, and externally provided C++ code? Not sure, FFI is not something that would've been used in any of the embedded systems I'd have recommended using Ada for. The language reference does specify how calling to C/C++, Fortran and Cobol code should function or be exposed within an Ada implementation. See the above PDF, it speaks a bit about FFI with C. [1] http://www.ada-auth.org/standards/ada12.html http://www.ada-auth.org/standards/ada12.html ----------------- A couple years ago I could've probably written up a better response, I've all but given up on Ada in my workplace. ----------------- EDIT: I should probably also confess a bit of an infatuation with good type systems and formal verification tools/processes. I've seen what results when these are absent, I've quit jobs because these were absent and the culture prevented any improvements. I'm not working on safety critical systems anymore, but if I ever end up back in those projects I will insist on using the right tools/processes. I don't want to wake up one day, turn on the news and read about a crash or malfunction that was caused or should have been prevented by my systems. Poor processes and tools enable these failures, and we should have zero tolerance for them. We have certifications/licensing for engineers (mechanical, civil, aerospace, electrical, etc.). If they sign off on a system/design that fails catastrophically and the failure should have been detected (via models or industry standards or whatever), they are held liable. Software developers in the safety/critical systems space have too cavalier an attitude, we're too well insulated from the aftermath of our defects. That attitude may never be changed, but a change in tools/processes to ones that contain, minimize or eliminate large classes of failures is certainly worth the effort.
Too 12y ago
Not my downvote but to me there's no wonder you got downvoted. Why is it no wonder these things don't fly? Are the rules too strict? too loose? too broad? too stupid? or is it the choice of language? Your post provides no insight into your opinion at all and added no value for anyone else, quite the contrary.