Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hackaday.com

Post reply on HN
Print view View original

241–250 of 330 posts

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

#241

Post by sterlind »

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…

You can and should check your specs like they're code. For instance, you can write the spec in TLA+, which lets you specify temporal properties (e.g. "can the stall recovery procedure take an unbounded amount of time?") and liveness properties (e.g. "can any non-majority of disagreeing sensors cause the wrong trim actuations?")

To test your invariants, you should sabotage the spec and check that invariants break.

Once your spec passes model checking (or perhaps theorem proving with TLAPS), you can codify it in e.g. ADA-SPARK contracts.

Once you have that, you've validated your spec, your contracts and your code. Bugs can only occur in your invariants and the seams of your subsystem. This level of rigor should be standard by now for safety-critical systems.

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

#242

Post by msla »

dreamcompiler wrote: post #171
microtherion wrote: post #162

Earlier quoted context omitted.

…for CS instruction. I've never come across any indication that Dijkstra wrote actual code (in the sense of something executing on a computer) after 1970 or so. The algorithms in the EWD notes are all written in ALGOL style pseudocode. Dijkstra was the CS equivalent of the Patent Law concept of a "Non-Practicing Entity", which gave him great liberty to troll all programming languages without exposing his own choices…

This nails it. Dijkstra sort of hated computers; he always hand-drew overhead projector transparencies for his lectures. He's also famous for saying we should call our field "Computing Science" because "Computer science is no more about computers than astronomy is about telescopes."

> "Computer science is no more about computers than astronomy is about telescopes."

It's more accurate to say that CS is no more about computers than aerodynamics is about flying: Without flight, aerodynamics would barely exist as a distinct field, and wouldn't be of interest to anyone except people in a sub-field of fluid dynamics, and never intersecting with practical concerns such as materials science and the overall design of buildable objects. Similarly with CS: Without computers it would be a simple, obscure sub-field of mathematics, about where it was in the 1930s when Post and Turing and Gödel were active, and it wouldn't intersect with fields like electronics or, probably, have much to do with formal grammars.

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

#243

Post by antocv »

jeffdavis wrote: post #40

There is some overlap in the use cases between Ada-in-the-mainstream (which seems to be what the article is suggesting) and Rust. The existence of Rust will make it even harder for Ada to break out of its existing domains. Both seem to have good ecosystems, but quite different. Ada has more high-assurance tooling and practices. Rust has more in terms of packaging and general-purpose high level libraries. With Ada, it…

I still cannot forgive Rust for not learning anything from Ada.

"Code is read more often than it is written". Reading Ada is so unambigous, and clear. If you mean if then, you have the keyword then, when you want to say procedure you say procedure and you can read that. Rust? fn, because is it fun, or functor, so fuck you.

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

#244

Post by vardump »

GnarfGnarf wrote: post #27

I've developed a set of "strongly typed" classes in C++ that have saved me a ton of grief. Here are some examples. All classes are fundamentally floats. Errors are caught at compilation. cInches i1, i2, i3; cCm cm1, cm2; i1 = 1.f; // error i1 = cInches(1.f); // OK i3 = i1 + i2; // OK cm1 = i1; // error i1 = i2 * 2.f; // OK float f1 = i1 / i2; // OK i1 = i2 * i3; // error! square inches are not inches int add(cInches…

I guess no one here bothered to actually benchmark scalar (like unit type/conversion code) floats vs doubles on modern x86 hardware. It will perform identically. Heck, don't believe me, check Agner's x86 instruction tables [0].

Please default to doubles and optimize only when it's actually an issue. 99% of cases it's not, unless you're doing throughput computing. In that case floats provide up to 2x improvement. Keep in mind modern x86 CPUs can perform up to 16 double precision FLOPs (FMA) per cycle per core — do you really think it's going to be the bottleneck in your code?

32-bit floats expose you to nasty issues with even "simple" stuff like errors in naively computed sums. Issues that mostly just wouldn't matter if 64-bit doubles were used. See a proper floating point summation algorithm [1].

That said, even 64-bit doubles (or any arbitrarily long imprecise format) won't shield you from all of floating point weirdness. But it sure does help in common cases.

With floats you'll get issues like this:

https://randomascii.wordpress.com/2012/02/13/dont-store-that...

[0]: https://www.agner.org/optimize/instruction_tables.pdf

[1]: https://en.wikipedia.org/wiki/Kahan_summation_algorithm

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

#245

Post by carlmr »

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…

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

That is true, but I found that in more strict languages you have a bit of a slower ramp-up, but the time you save later before production in bugs you don't have could be used to take more looks at the spec and better simulations.

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

In this particular case yes, however if the system was actually needed for flight (which I would guess most software is), it might be better to reset and retry.

On average if your language fails hard like ADA it's also more likely to find these bugs in simulations and tests.

Rust might have solved the problem the way you like it. Integer overflow causes exceptions only in Debug mode, not in Release mode.

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

#247

Post by MayeulC »

harry8 wrote: post #201
vore wrote: post #198

Earlier quoted context omitted.

For mission-critical software like avionics or a nuclear power plant? Absolutely! At design time you better figure out what all the error cases are, and blindly steamrolling over them when they should be triggered makes a bad problem worse (e.g. look at Cloudbleed where unchecked out-of-bounds reads starts disclosing other people's banking information). Assertions are also usually turned off for performance reasons,…

Uncaught exception and die. For a banking application, yes, die, hard, as loudly as possible. Downtime is worth it. Do not continue, do nothing until it is understood and fixed. When you're flying. Hmmm. Not so much. Dying is a really bad idea. Ok you should have it tested thoroughly so it isn't going to happen but if it does and "anything could happen" well "anything" is better than killing all the passengers, crew…

Well, for an unmanned rocket, have it automatically self-destruct is likely the saner choice, as you don't want it to fall back somewhere inhabited, and there is usually little use for something on the wrong orbit.

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

#248

Post by irundebian »

vardump wrote: post #79
blub wrote: post #59

Earlier quoted context omitted.

That seems like a trick question, because obviously you wouldn't pick Ada, you would pick Rust. And then you would talk about Rust, and mention how great Rust is, perhaps in a thread about Ada, which hadn't mentioned Rust at all. Or a thread about C, or about C++ or even about Go or why not even Python and JavaScript. But seriously now: the author didn't mention Rust because they probably don't even know it exists. I…

I'd really love to read a fair and comprehensive comparison and review of Ada and Rust. Safety, performance, concurrency, low level ABI compatibility etc. Ada does seem interesting, but all the buzz seems to be about Rust. Perhaps Ada deserves more interest?

At least a short comparison of Ada/SPARK and Rust:

https://www.electronicdesign.com/industrial/rust-and-spark-s...

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

#249

Post by Ono-Sendai »

antocv wrote: post #243
jeffdavis wrote: post #40

There is some overlap in the use cases between Ada-in-the-mainstream (which seems to be what the article is suggesting) and Rust. The existence of Rust will make it even harder for Ada to break out of its existing domains. Both seem to have good ecosystems, but quite different. Ada has more high-assurance tooling and practices. Rust has more in terms of packaging and general-purpose high level libraries. With Ada, it…

I still cannot forgive Rust for not learning anything from Ada. "Code is read more often than it is written". Reading Ada is so unambigous, and clear. If you mean if then, you have the keyword then, when you want to say procedure you say procedure and you can read that. Rust? fn, because is it fun, or functor, so fuck you.

Do you really want to type out 'procedure' thousands of times?

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

#250

Post by vardump »

irundebian wrote: post #248
vardump wrote: post #79

Earlier quoted context omitted.

I'd really love to read a fair and comprehensive comparison and review of Ada and Rust. Safety, performance, concurrency, low level ABI compatibility etc. Ada does seem interesting, but all the buzz seems to be about Rust. Perhaps Ada deserves more interest?

At least a short comparison of Ada/SPARK and Rust: https://www.electronicdesign.com/industrial/rust-and-spark-s...

Thanks, while short, it sure looks interesting.

SPARK statically checked function pre- and postconditions and constrained types certainly look very interesting especially for embedded systems. And for a lot of other low level code as well.

Post reply on HN