Live data from Hacker News

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

hackaday.com

211–220 of 330 posts

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

#211
post #165

Earlier quoted context omitted.

Wasn't the ill fated code itself written in Ada? That is essentially all that goes on boeing aircraft. I don't think a lack of software engineering rigor is to blame for the design mistake.

Possibly; I don't work for Boeing or their subcontractor. But I was getting at more of the general sense that as aircraft become more and more computerized we need more rigour and standardization of the sort that gave rise to Ada, and less of the aerospace equivalent of hacking things together in perl.

I would say we need more real rigor, of the kind that gave us qmail and seL4, and less fake rigor, of the kind that gave us Ada and inevitably proceeds from standardization.

Standardization means less autonomy, which generally means that the opinions of prestigious people are imposed on everyone else. This can be good for intellectual rigor at first if your social pecking order is based on having sound opinions, like St. Augustine, but if it's based on anything else, standardization is an intellectual disaster from the start. And of course standardization prevents intellectual progress, always and everywhere, which is how Galileo ended up under house arrest.

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

#212
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…

> 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, a…

Mostly I agree, but the engineers and managers weren't just accepting the Ada language defaults here; they had consciously decided, after clearly not enough testing, that the best thing to do if there was an unhandled error was to shut down the SRI, because it was probably a hardware failure. So using Rust, which I do agree is much better than Ada and provides safety guarantees Ada doesn't even dream of, wouldn't have saved them; they would have chosen to panic.

Also Ada does have wrapping arithmetic available. It just isn't the default.

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

#213
post #183

Earlier quoted context omitted.

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…

This conversation is everything I love about HN. Thoughtful, informative conversation, correction without offense--and so we all benefit. Thank you guys and thanks to dang for keeping this such a great forum!

Well, I probably could have corrected more politely, too, but I appreciate that ajxs suffered fools gladly in this case, the fool being me.

Also as long as we're buttering up the mods, don't forget sctb!

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

#214
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.

105 launches, 2 failures, 3 partial failures. That's a 95,2% success rate.

That's a normal failure rate for chemical rockets. The notable thing was that the first failure was due to software.

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

#215
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…

> 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, a…

You could have condensed your entire post to just "This exception was uncaught". Your last point is just outright ridiculous:

> "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"

So... What you're trying to tell us is that Ada recognising an exceptional situation has occurred is bad, and that Rust just ignoring it is a good thing? Righto... An integer overflow occurring in this scenario is an exceptional condition. In this case it was one that the developers did not anticipate. This issue arose because they mistakenly thought it was not possible for this scenario to occur. The mistake here was not anticipating the exception and handling it in a meaningful way, not the raising of an exception. The fact that not raising an exception would have avoided the disaster in this case is entirely incidental. It was still an exceptional circumstance that the developers, testers, designers did not anticipate. The silent wrapping behaviour you describe would have bitten someone eventually, perhaps here, perhaps somewhere else. Possibly with enormous repercussions.

> "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."

The normal "unsafe" languages you're referring to ( presumably C ) have a history of very poor error handling. Requiring an extremely high degree of conscientiousness when programming for mission-critical applications. Can you imagine actually programming for what you're describing here? Not only does the computer have to guard against outright failure, but now it has to infer the possibility of an error state from a stream of in-band data in real-time. Righto...

Also, just so you know: Signed integer overflow is UNDEFINED BEHAVIOUR in C.

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

#216
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…

The issue with Ariane V was the lack of integrated testing. If they had coupled the testing of the software with increased acceleration levels generated by a simulated Ariane V instead of an Ariane IV, they would have caught the issue.

But let's say this was something unexpected - then probably the only way to mitigate this would be a backup system - but this is an unmanned system - and Apollo/Saturn/Shuttle/Soyuz levels of redundancies is not required.

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

#217

What about Forth? I quite like the way it eschews too much abstraction and can go from very low level to high level with a lot less code (and less bugs). Given the current interest with IoT and the proliferation of cheap micro controllers it might be due for a resurgence(?).

I like Forth but I always seem to make my programs too clever in it. If I write them in C or assembly instead it takes longer but has less bugs. Probably people with better self-discipline than I have can do wonders in Forth.

Current micros are a bit big for Forth, though. You can run C or C++ on them. If you have only 4K or 8K of code space and 128–512 bytes of RAM the case for C over Forth gets a lot weaker. Maybe we'll see a resurgence of Forth when we get nanobots.

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

#218
post #195

Earlier quoted context omitted.

>> 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 is miles ahead of Rust when it comes to C interoperability. I posted this before in one of the other Rust threads, but you can't get more than two paragraphs through the official Rust FFI documentation ( https://doc.rust-lang.org/nomicon/ffi.html ) before being asked to install a third-party dependency. The 'Interfaces.C' package is defined in the Ada language specification. And, as others have mentioned, Ada's l…

There's nothing wrong with pulling in the `libc` dependency. It literally means adding two lines of code and then `cargo` manages everything for you. It isn't really third-party; the owner is "rust-lang:libs".

I understand that people are conditioned to think APIs are easier to consume when they're in the standard library, because that's true in many languages, especially those that lack a modern package management system (e.g. Ada). But it's not true in Rust and there are advantages to having libraries like `libc` outside the standard library. For example `libc` is updated more frequently than the Rust standard library (multiple times per month vs every six weeks).

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

#219
post #72

This article promotes a popular misconception of the programming situation for defense projects in the 1970s. There may have been "hundreds of specialized programming languages" in existence that could be used, but just a handful actually predominated. Most aeronautical projects were done in JOVIAL. I've talked about this history with engineers from the 1960s-70s. They did not regard the introduction of Ada as a good…

production JOVIAL code was like.... 20 lines of comments. 1 line of code. 20 lines of comments. 1 line of code.
Post reply on HN