> The Ariane 5 explosion was not a programming error, it was a testing and specification error.
What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.
It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.
> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.
That's immensely different actually ... One is undefined behavior, the other is defined but crash. In the first case the problem can stay unnoticed almost forever until somebody exploits it. In the second case, if you actually test and cover your code, you will catch the problem.
Short for using a proof technology (which Ada enables and makes easy because of the large palette of constraints you can add on types), there is NO language that can statically guarantee that your program won't crash at runtime. Yes, Ada is not special in that regard. What Ada guarantees is that it will crash, so you can actually catch those kind of bugs in testing. Also nowadays you can use SPARK Ada to formally prove your code correct. https://en.wikipedia.org/wiki/SPARK_(programming_language)
Blaming on the language what is actually bad testing/architecture is pretty unfair.
> It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.
Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time. I have never seen anybody saying that it was because Ada was "not safe enough", and even today it stays one of the safest languages out there in many aspects.
> Blaming on the language what is actually bad testing/architecture is pretty unfair.
I think we can both agree that a SEGFAULT and an unhandled CONSTRAINT_ERROR lead to program termination.
Your right in that at least Ada raised a CONSTRAINT_ERROR. But -- the cause for a CONSTRAINT_ERROR and a SEGFAULT in this case are the same: bad handling of inputs to a function.
So in this case the results would have been the same as well. In either case it comes down to design and proper handling of inputs.
So I don't buy your argument that it is different because of undefined behavior vs. defined behavior. Ada 83 had undefined behavior, too. It's just that Ada coders (well the good ones) knew to avoid it.
> Do you have any source for that ? From my sources, Ada got less and less traction because of various reasons, one of them being the price of compilers at the time.
Having worked in a Large Defense Corp(TM) during the height of the Ada popularity, it became pretty clear that the cost of a compiler for a $100mm program wasn't really the issue.
The GNAT Ada compiler came out in 1995, and I know smaller defense contracts used that as a viable solution to write software.
The primary issues with Ada were:
1. Ada was oversold and underperformed. The Arianne-5 was the kind of tragedy that Ada was supposed to prevent. Interfacing with external systems was a pain. Tooling was a pain. The resulting executables were HUGE at the time.
And then the development itself was expensive. Towards the end of my time writing Ada, our group was coding at the rate of 2 lines of Ada code / developer hour. Compiling took hours, running and testing took hours, etc. So a 20 line code change might easily result in 10 hours of a compiling/testing cycle.
2. No code reuse across defense contractors. Ada didn't have a package manager at the time, and while there were software libraries, there weren't a lot of them. Not like the C/C++ or later the Java world would have. So if you needed something, most likely you had to write it from scratch.
3. Java got popular around 2000ish and showed what a great software ecosystem looked like. Around 2005ish most new successful defense development was on java.
> What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.
That's completely wrong. It was an integer overflow. One that could not happen on Ariane 4 but because of different hardware specs. But that was only the end of the chain of fails that lead to the crash.
Ada is of course completely able to handle such a problem. But the programmers evaluated this and consciously decided not to handle it for performance reason and because it shouldn't happen anyway. But it could happen, just only on the Ariane 5.
Sorry to be blunt but I don't think you know as much as you think you do. You should read up more on the incident. You could even read the post mortem report. It is available on the net.
What happens when you stick a 32bit float into a 16bit float type in Ada? CONSTRAINT_ERROR. And this could happen at runtime, not compile time. It was Ada's inability to deal with unknown/incorrect inputs and deal with them in an effective way without crashing. This is not that much different than buffer overflows from unknown inputs in C, btw.
It's worth noting that this was one of the primary reasons that Ada got less and less traction in the US government, as Ada was supposed to prevent things like this from ever happening.