Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is certainly an impressive list of projects. Ada seems to be favored for critical software that can't ever fail. I've been considering how to achieve this type of software reliability for more "enterprisey" applications. Formally verifiable languages are certainly intriguing, but would be a hard sell for the managers at the Fortune 100 company where I work.

Reading the wikipedia page for Ada didn't really give much insight into why the language is so heavily favored for applications like avionics software. Built in task based concurrency is certainly nice, but not a game-changer. Can someone more familiar with Ada explain what makes it so popular for high reliability applications?

Or is it a question of culture and tooling rather than the language itself?



It has a lot of safety checks built into the runtime, which make it a little slower.

x is and int between 1 and 200.

x gets asigned out of that range, exception is thrown. So we weren't manually checking everything.

Also I think it was mandated as a language for US government contracts, for a variety of reasons.


As with asserts in C, you can compile with that turned on or off.


Like C, it's been around forever and is considered battle-proven and figured-out. Unlike C it has real-time features and a type system that isn't trying to kill you.

Also the syntax is designed to be as easy to understand as possible, typing out every word and using no three-letter abbreviations.

It's in general a language that was way ahead of its time, but survived because the DoD mandated it. Its main competitor is C, but that's mostly because the amount of engineers who know Ada out of school is really low, which is a shame, I think. Rust is way too new and Haskell has GC.


Or is it a question of culture and tooling rather than the language itself?

Pretty much. I write software for Medical Devices and culture and process is what it boils down to. Tooling helps. We use C, C++, C# among other languages. Language makes a little difference in reliability, but not much.

What matters in a nutshell: Know what you're building: need good Requirements

Analyze those Requirements for correctness, clarity and uniqueness (no conflicts)

Make sure your design meets all the Requirements and doesn't add anything: if you add a feature not in a Requirement, how will the testers know it's there? Verify the design: i.e., does it do what you need and does it do it "well." Does it barely function, or will it handle what you expect to be thrown at it or fail gracefully? Separate the concerns: e.g., need to be sure that the temperature is correct? The temperature control code and the temperature verification code should be decoupled from each other.

Code: probably where language makes the most difference, although different languages will influence your design.

Verify all design artifacts: review your Requirements, Designs, and all Code against predetermined quality standards. Reject anything that doesn't meet the standard. Build what you planned to build, and document what you built. Most errors will stem from Requirements problems.

That's Software Quality in a tiny nutshell ;-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: