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

281–290 of 330 posts

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

#281

Post by antocv »

Ono-Sendai wrote: post #249
antocv wrote: post #243

Earlier quoted context omitted.

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?

Yes of course, even if my IDE doesnt autocomplete anyway. Code is read much more often than it is written.

Yes, I do want to read out what I type and possible speak it to collegues without sounding like I have a fn seizure.

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

#282

Post by JulianMorrison »

When I played with Ada, my feeling was that it allowed a lot of things to lean on the types, protection is one that gets made a lot of fuss about, but also there's a lot of labour saving. You can size something to the length of something else. You can get the max and min of a type (which are user defined, not tied to byte sizes). You can get an array's bounds. Everything "reflows" if you edit the type definitions. It allows you to be very detailed about what you want, and then let other parts of the program lean on that detail. Types become more than a way to catch mistakes, they become a way to describe your intentions.

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

#283

Post by blub »

kragen wrote: post #221
ajxs wrote: post #215

Earlier quoted context omitted.

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 g…

Tainting the dataflow rather than the control flow, like a quiet NaN, would be a better solution in cases like these. It happens that the solution that was chosen was the worst choice possible, but in other cases it wouldn't have been. Probably the fact that the engineers got the case analysis wrong suggests that the methods of reasoning they were using weren't very effective. Modern formal methods might or might not…

In hindsight it would have been perhaps better, but I don't think it can be said that having essentially random values in memory is better than having a controlled error handling action being executed. Is there any reference that such a course of action is preferred or beneficial?

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

#284

Post by bdavis__ »

shakna wrote: post #175
devnulloverflow wrote: post #148

Earlier quoted context omitted.

> Just the mojo required to print an integer (having to instantiate a generic) was considered complicated That sounds complicated to me, in 2019 with 25 years of C++ experience. (And of course C++ error message sprouting mysterious stdlib templates also seems complicated to me).

It isn't more complicated than printf, which is also close to being a generic. PutLine("The number is " & num); printf("The number is %zu\n", num);

pakage int_io is new integer_io (num=>integer);

and then

int_io.putline(num);

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

#285

Post by w8rbt »

ajxs wrote: post #189
nwallin wrote: post #181

Earlier quoted context omitted.

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 implem…

C would recognize it, but not over-react. Log it and continue rather than going full abort/self destruct which is what ada did.

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

#286

Post by fluffything »

devnulloverflow wrote: post #148
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…

> Just the mojo required to print an integer (having to instantiate a generic) was considered complicated That sounds complicated to me, in 2019 with 25 years of C++ experience. (And of course C++ error message sprouting mysterious stdlib templates also seems complicated to me).

> That sounds complicated to me, in 2019 with 25 years of C++ experience.

std::cout is not a generic, but on the project I just tested, if I substitute X with a type that does not implement an appropriate operatorI personally find having to do overload resolution first on a 1000 function overload set containing generic and not generic functions, and then often having to actually instantiate a generic (doing template argument deduction, template instantiation, substitution-failure is not an error so the next overload might be picked, etc. etc. etc.) infinitely more complicated than "just" instantiating a generic.

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

#287

Post by shakna »

dawidw wrote: post #266
shakna wrote: post #175

Earlier quoted context omitted.

It isn't more complicated than printf, which is also close to being a generic. PutLine("The number is " & num); printf("The number is %zu\n", num);

printf is not c++

Ada is the one that was considered complicated. Making use of PutLine in the way I demonstrated was, at the time, considered complicated and confusing.

That it's as easy as printf demonstrates the changes in thinking to today fairly well.

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

#288

Post by johnisgood »

Fabien_C wrote: post #275
carlmr wrote: post #271

Earlier quoted context omitted.

> Rust just ignoring it is a good thing? Rust tries to give you zero-cost abstractions where possible. Overflow checks aren't zero-cost, therefore they're disabled in release mode. Otherwise when safety can be done at zero-cost (at runtime) Rust will usually do that. I agree with you though that the exception might have helped in many other situations, especially if a simulation catches it early on. I would still say…

I don't see the point with "zero-cost abstractions", overflow check is not an abstraction. And of course the run-time checks can also be disabled for Ada of course, and usually are for release build.

And this is worth noting:

> These runtime checks[1] are costly, both in terms of program size and execution time. It may be appropriate to remove them if we can statically ensure they aren't needed at runtime, in other words if we can prove that the condition tested for can never occur.

> This is where the analysis done by GNATprove comes in. It can be used to demonstrate statically that none of these errors can ever occur at runtime. Specifically, GNATprove logically interprets the meaning of every instruction in the program. Using this interpretation, GNATprove generates a logical formula called a verification condition for each check that would otherwise be required by the Ada (and hence SPARK) language.

[1] overflow check, index check, range check, divide by zero

---

So again, I do not see why Rust would shine (as some people suggested) here, Ada/SPARK can statically ensure that your program is correct and eliminate all sorts of runtime errors, including overflow.

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

#289

Post by ff317 »

wycy wrote: post #279
harry8 wrote: post #201

Earlier quoted context omitted.

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…

Whether die-hard or steamroll-thru is the better option depends more on what exactly goes wrong rather than what the application is. For a flight control computer, for example, if the ordered pitch suddenly becomes 3.402823466e+38 degrees it might be better to die hard and restart rather than try to execute the order.

I imagine (just thinking out loud randomly, I'm sure there's other issues to consider!) one way to mitigate this would be to have a second set of much simpler software (written in a different language, perhaps running on a different platform) whose only runtime job is to sit in the communications path from the primary software to the avionics hardware and monitor the outputs of the primary software and ensure the values and/or rate-of-change in certain values are within some physics-based sanity limits before they hit the hardware. It could be responsible for rebooting the primary software and holding the last-known-good output values (for the consuming avionics) while the reboot happens (hopefully quickly!). Of course then who watches the watcher, and you've added more things in the critical path which can have their own failure modes...

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

#290

Post by shakna »

bdavis__ wrote: post #284
shakna wrote: post #175

Earlier quoted context omitted.

It isn't more complicated than printf, which is also close to being a generic. PutLine("The number is " & num); printf("The number is %zu\n", num);

pakage int_io is new integer_io (num=>integer); and then int_io.putline(num);

    with Ada.Text_IO; use Ada.Text_IO;
    with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;

    ...

    PutLine(num);
As far as I can tell, Ada has had Integer_Text_IO that does that all for you, since the early days. [0] (Note that the reference is the first "public" release of Ada outside of the DOD).

[0] https://www.adahome.com/LRM/83/RM/rm83html/lrm-14-03.html#14... (Ada 83 Manual)

Post reply on HN