Why Ada Is the Language You Want to Be Programming Your Systems With • Hacker News Board

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#181

Post by nwallin » Wed, Sep 11, 2019, 2:15 AM UTC

na85 wrote: post #137

bdavis__ wrote: post #91

Earlier quoted context omitted.

Many of the 'programmers' of those days lacked the sophistication and education to appreciate Ada. Just the mojo required to print an integer (having to instantiate a generic) was considered complicated Ada was also very slow to compile, on the order of 10 times slower than Jovial. (my experiences) Avionics systems back then were tiny. Jovial usually ran on a 16 bit processor. Ada enabled a certain maturity and corre…

I can sympathize with resistance to Ada in a sense: Big "enterprise-y" languages can feel unwieldy and cumbersome if you're used to bit-twiddling and struct-packing in something like C. But as the recent Boeing debacle has shown, the avionics domain is in need of greater sophistication and reliability. What it doesn't need is more hackery, as satisfying as that may be for the hardware hackers. Though Ada isn't a mass…

The software in the case of the 737 max performed exactly according to the spec. The problem is that the spec was buggy. The language can't fix a buggy spec.

Note that the bug which caused the Ariane V disaster was written in Ada. And that was caused by the language. If the Ariane V code was written in C and the value simply overflowed, nothing negative would have happened. (The value would be hilariously wrong, but that wouldn't have mattered because the code wasn't necessary during flight. It was an oversight that it was running at all.) However, this is Ada, so it caused an integer overflow exception. Which was uncaught. Which caused the entire system to nope out. Which caused the rocket to blow up.

So there's that to consider.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#182

Post by naikrovek » Wed, Sep 11, 2019, 2:19 AM UTC

mycall wrote: post #168

naikrovek wrote: post #136

Earlier quoted context omitted.

I'm sure that's all true. There is something to be said for a language that was written to a spec from the beginning, however. That is a luxury that few languages today can claim; most language specs were written after the first version(s) of the language were implemented, and were written to match the implementation, not the other way around. Writing the specification first makes for a much cleaner language, though…

Calling one language better than another is subjective and open to interpretation. Clean might not be as important as critical mass in adoption, letting people more efficiently find people to work on the software.

That depends. If you are looking for a language that produces more work for the CPU per line of source code, that is definitely not subjective. Programming languages are not hard to learn for anyone that already knows one or more.

Other important metrics no one thinks to measure:

* Quality of compiled assembly or bytecode (it is dead easy to write a shitty compiler that produces stupid assembly or bytecode)

* Runtime performance on tight loops (this is directly tied to cost when running on something like AWS Lambda, and code that performs well means you need to upgrade your hardware less often)

* Lines of code required to achieve a given goal. Less is obviously better, when you understand that more code = more complexity, and that more complexity = higher likelihood of bugs. Also, if there is enough boilerplate code to break these guidelines, then what is that code doing, except slowing development times and slowing execution times?

I can write a method two or more ways and know provably which is faster. No one does this! No one looks for hot spots and tries to optimize them. No one profiles anything if performance is deemed "good" or "not a problem."

There is a lot of CPU time to be saved, a lot of RAM usage and cache optimization that no one does because they believe that their work is above being challenged, even by themselves. This world is insane.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#183

Post by ajxs » Wed, Sep 11, 2019, 2:24 AM UTC

kragen wrote: post #166

ajxs wrote: post #133

Earlier quoted context omitted.

There's always someone who brings this up whenever Ada is mentioned, as if it serves as a damning refutation of Ada's reputation as a safe language. That bug was caused by a series of design failures if anything, rather than software bugs. From memory, they reused the inertial reference system from the Ariane 4 mission without testing its suitability for a different delivery vehicle. The actual 'bug' was caused by an…

> It's not some software bug caused by Ada. This is not correct. It was, in fact, "some software bug caused by Ada", in the sense that in most other programming languages, the error that did in fact happen would have been harmless. For those who are interested, the full report is at http://www-users.math.umn.edu/~arnold//disasters/ariane5rep.... . There is no need to "guess" when a fairly detailed public analysis is…

Forgive the use of "from memory" in my original post. I was on the move and didn't have time to reference the original material in-depth. You're correct. You've given a great explanation of the accident. Whenever this is brought up, I feel the need to rebuke the insinuation that this accident was explicitly caused by the use of Ada. You are correct in that the accident was the result of an exception caused by an overflow, something that might not have triggered an exception condition in another language. However, I don't think the fact that a language like C might never have realised there's a problem at all to be damning of Ada. No matter what language this was developed in, better formal analysis of the problem domain should have highlighted the possibility that this could occur. Especially considering the different hardware involved.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#184

Post by thesuperbigfrog » Wed, Sep 11, 2019, 2:26 AM UTC

phkahler wrote: post #169

ajxs wrote: post #133

Earlier quoted context omitted.

There's always someone who brings this up whenever Ada is mentioned, as if it serves as a damning refutation of Ada's reputation as a safe language. That bug was caused by a series of design failures if anything, rather than software bugs. From memory, they reused the inertial reference system from the Ariane 4 mission without testing its suitability for a different delivery vehicle. The actual 'bug' was caused by an…

>> he actual 'bug' was caused by an integer overflow occurring due to the velocity variable not being wide enough to handle the higher horizontal velocities of the newer rocket. Something all that fancy type system should have prevented. I found it interesting in the Hackaday piece that the C code xample called out the size of an integer while the Ada version did not. The Ada version caught an implicit conversion, bu…

Ada / C interop is very easy to do.

https://learn.adacore.com/courses/intro-to-ada/chapters/inte... shows how Ada's Interfaces.C package and the Import and Export aspects are used to share data and make function calls between Ada and C.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#185

Post by kragen » Wed, Sep 11, 2019, 2:27 AM UTC

ajxs wrote: post #183

kragen wrote: post #166

Earlier quoted context omitted.

> It's not some software bug caused by Ada. This is not correct. It was, in fact, "some software bug caused by Ada", in the sense that in most other programming languages, the error that did in fact happen would have been harmless. For those who are interested, the full report is at http://www-users.math.umn.edu/~arnold//disasters/ariane5rep.... . There is no need to "guess" when a fairly detailed public analysis is…

Forgive the use of "from memory" in my original post. I was on the move and didn't have time to reference the original material in-depth. You're correct. You've given a great explanation of the accident. Whenever this is brought up, I feel the need to rebuke the insinuation that this accident was explicitly caused by the use of Ada. You are correct in that the accident was the result of an exception caused by an over…

I agree.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#186

Post by waynecochran » Wed, Sep 11, 2019, 2:36 AM UTC

Ada was the language of the undergraduate curriculum at the University of Washington when I was there (late 1980's) -- because Boeing. One of the core safety mechanisms was exception handling.

* The biggest thing I miss is that every block was inherently a try-block. Just put your exception handlers at the bottom of the block. This provided a nice separation of "normal flow-control" and "exceptional flow-control". Why have try-catch anyway -- I never got used to that later in life.

* Exceptions were not synonymous with errors. In fact the way to read a file byte by byte was just to keep reading bytes and never explicitly check for end-of-file. Let the exception handler handle this case. Logic is much cleaner.

* Remember that you can't just dump core and shell out to the OS on an un-handled exception -- not if your controlling a ICBM flying of the continent. Ada really forced you to handle all errors at some level of the call-stack with an exception handler. At the outer-most level -- just call self-destruct.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#187

Post by nwallin » Wed, Sep 11, 2019, 2:37 AM UTC

ajxs wrote: post #133

ch_123 wrote: post #32

> Ada code controls rockets like the Ariane 4 and 5, many satellites, and countless other systems where small glitches can have major consequences. A somewhat amusing endorsement given that the infamous failure of the maiden launch of the Ariane 5 due to series of interconnected software bugs - a reminder perhaps that the choice of implementation language does not automatically make for a reliable system.

There's always someone who brings this up whenever Ada is mentioned, as if it serves as a damning refutation of Ada's reputation as a safe language. That bug was caused by a series of design failures if anything, rather than software bugs. From memory, they reused the inertial reference system from the Ariane 4 mission without testing its suitability for a different delivery vehicle. The actual 'bug' was caused by an…

> The actual 'bug' was caused by an integer overflow occurring due to the velocity variable not being wide enough to handle the higher horizontal velocities of the newer rocket. This caused the rocket to go off course and require termination.

This is not entirely correct. The code which overflowed was unnecessary for flight. People have this idea that the sensor sensed it was going 32745 m/s to the east one moment, and -32723 m/s the next, and then tried to compensate for the sudden gust of wind it must have encountered. This is incorrect. The routine in question was only supposed to run when it was on the ground, and served no purpose in flight. It was scheduled to be disabled 40 seconds after launch. (The flight failed after 37 seconds)

The problem is specifically the fact that the code was written in Ada. Ada does not fail the way other languages fail when you overflow. Instead of given an incorrect value (which never would have impacted the flight) it throws an exception. This exception was uncaught. This uncaught exception brought down the entire flight control system, despite the fact that the falling code was not controlling flight.

Rust improves upon this situation by panicking in debug mode and wrapping in release mode, which is better than the Ada behavior in every possible way. Normal "unsafe" languages improve this by giving an incorrect value as the result, which in the case of Ariane V would have saved the flight.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#188

Post by realusername » Wed, Sep 11, 2019, 2:39 AM UTC

waynecochran wrote: post #186

Ada was the language of the undergraduate curriculum at the University of Washington when I was there (late 1980's) -- because Boeing. One of the core safety mechanisms was exception handling. * The biggest thing I miss is that every block was inherently a try-block. Just put your exception handlers at the bottom of the block. This provided a nice separation of "normal flow-control" and "exceptional flow-control". Wh…

> * The biggest thing I miss is that every block was inherently a try-block. Just put your exception handlers at the bottom of the block. This provided a nice separation of "normal flow-control" and "exceptional flow-control". Why have try-catch anyway -- I never got used to that later in life.

That's still the case in Ruby, you can put a rescue at the end of the block.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#189

Post by ajxs » Wed, Sep 11, 2019, 2:42 AM UTC

nwallin wrote: post #181

na85 wrote: post #137

Earlier quoted context omitted.

I can sympathize with resistance to Ada in a sense: Big "enterprise-y" languages can feel unwieldy and cumbersome if you're used to bit-twiddling and struct-packing in something like C. But as the recent Boeing debacle has shown, the avionics domain is in need of greater sophistication and reliability. What it doesn't need is more hackery, as satisfying as that may be for the hardware hackers. Though Ada isn't a mass…

The software in the case of the 737 max performed exactly according to the spec. The problem is that the spec was buggy. The language can't fix a buggy spec. Note that the bug which caused the Ariane V disaster was written in Ada. And that was caused by the language. If the Ariane V code was written in C and the value simply overflowed, nothing negative would have happened. (The value would be hilariously wrong, but…

> "If the Ariane V code was written in C and the value simply overflowed, nothing negative would have happened"

So... what you're saying is that the language not recognising an exception conditional has occurred is a better outcome in mission critical applications? "wasn't necessary", "It was an oversight", "Which was uncaught"... With these phrases you've already pointed out that the developers had improperly implemented the application.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#190

Post by baot » Wed, Sep 11, 2019, 2:44 AM UTC

snazz wrote: post #164

kahlonel wrote: post #82

As a side note for people like me who have no option other than C for their safety critical projects, remember there's a MISRA-C standard. If that feels too much, [1] is a good starting point. [1] http://pixelscommander.com/wp-content/uploads/2014/12/P10.pd...

Thank you for the link! I think that’s really helpful and those are good explanations for each rule. Does anyone know of a guide for writing C code where you allocate a specific block of memory at the start and then use that for all data from then on? Avoiding malloc is one of the suggestions there and seems like a smart strategy.

I've written code exactly like that and realised that it just kicks the can down the road: you're still allocating memory from a fixed block, it's just now the malloc is written by you, with more bugs, and you still need to deal with variable allocation delays and running out of memory. The real issue is if you don't know at compile-time what resources you'll need at run-time. For some problems that can be an intractable problem for making a safe product, including, to my knowledge, everything that runs on a rich OS.