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

271–280 of 330 posts

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

#271

Post by carlmr »

ajxs wrote: post #215
nwallin wrote: post #187

Earlier quoted context omitted.

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

> 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 from gut feeling that ADA makes the safer decision on average.

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

#272

Post by LandR »

alxlaz wrote: post #251
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,…

This is a slightly more complicated topic (i.e. it's complicated by whether or not manual recovery is possible and by whether or not carrying on makes it worse), but in general, the worst thing you can do if you encounter an error in the software that supervises a process is to bail out and leave the process unsupervised. A chemical reaction, for example, is happy to carry on whether or not computers are watching. Th…

In the Boeing case why wasn't there a button the pilot can hit that says "The computer is acting up, it's going to crash, turn it off and let me fly the plane"

Surely, the pilot should always be able to have the last say in where or what the plane is flying toward? Or are these planes now so complicated the pilots can't fly them without the computers?

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

#273

Post by olzd »

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?

You type 'proc' and let the editor autocomplete that for you: this is a long solved issue.

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

#274

Post by carlmr »

baot wrote: post #190
snazz wrote: post #164

Earlier quoted context omitted.

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

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

You're right, but you should still constrain yourself to these few instances to use malloc instead of wildly using it everywhere.

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

#275

Post by Fabien_C »

carlmr wrote: post #271
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…

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

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

#276

Post by relic »

LandR wrote: post #272
alxlaz wrote: post #251

Earlier quoted context omitted.

This is a slightly more complicated topic (i.e. it's complicated by whether or not manual recovery is possible and by whether or not carrying on makes it worse), but in general, the worst thing you can do if you encounter an error in the software that supervises a process is to bail out and leave the process unsupervised. A chemical reaction, for example, is happy to carry on whether or not computers are watching. Th…

In the Boeing case why wasn't there a button the pilot can hit that says "The computer is acting up, it's going to crash, turn it off and let me fly the plane" Surely, the pilot should always be able to have the last say in where or what the plane is flying toward? Or are these planes now so complicated the pilots can't fly them without the computers?

There are...there are multiple levels of auto-pilot to turn off, but the pilot can have pretty much full control.

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

#277

Post by Mikhail_Edoshin »

ernst_klim wrote: post #265
Mikhail_Edoshin wrote: post #256

Earlier quoted context omitted.

This is hardly possible. The whole idea of exceptions is that each function only deals with a subset. If no one does this, there's always a top-level handler that handles all. The default handler normally terminates the program, but it's totally possible to write a custom top-level handler that does something else. E.g. normally "out of memory" is an exception that causes a program to terminate, but in old Adobe Phot…

> This is hardly possible. The whole idea of exceptions is that each function only deals with a subset. Why? It's totally possible to infer the most general type for all the functions in the program, hence to infer the type of the needed handler. Any language with subtyping and powerful type inference can do this, here is the toy ocaml example with typed algebraic effects (you can think of them as of exceptions): val…

It's possible to compute which exceptions can be raised, but it's impractical to handle each exception in each function (this is how I understood your comment, I guess this is not what you meant). E.g. nearly any call can technically raise an OutOfMemory error or an IntegerOverflow error, but most functions are not competent enough to handle that, all they can do is to clean up and raise this up the call stack.

But it is indeed possible to have a single top-level handler (or a carefully constructed hierarchy of handlers) that explicitly handle all exceptions that may arise. (And to ignore an exception is also a form of handling.) The handler already exists, but it's pretty simple: for any exception it prints the error and terminates the program. It's up to developer to override this to make the program more robust.

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

#278

Post by alxlaz »

LandR wrote: post #272
alxlaz wrote: post #251

Earlier quoted context omitted.

This is a slightly more complicated topic (i.e. it's complicated by whether or not manual recovery is possible and by whether or not carrying on makes it worse), but in general, the worst thing you can do if you encounter an error in the software that supervises a process is to bail out and leave the process unsupervised. A chemical reaction, for example, is happy to carry on whether or not computers are watching. Th…

In the Boeing case why wasn't there a button the pilot can hit that says "The computer is acting up, it's going to crash, turn it off and let me fly the plane" Surely, the pilot should always be able to have the last say in where or what the plane is flying toward? Or are these planes now so complicated the pilots can't fly them without the computers?

I'm a bit out of my waters when it comes to aerospace, hopefully someone more familiar with the field can correct me if I'm wrong on any of these accounts. I knew I should have given examples from the medical field, but the parent post mentioned airplanes and nuclear plants so...

Airplanes that cannot be flown without computers definitely do exist. The F-117 is perhaps the most famous. Its shape makes it aerodynamically unstable on all three axes and it needs constant correction from the FBW system. Which has quadruple redundancy :). You can turn off the autopilot in these systems, obviously, so you get to say where it goes -- but without the FBW system to issue corrections, the plane crashes.

As for Boeing (or Airbus, who have this ELAC thing)... the main thing to understand here is that there is not a computer. There are several computers, each of them covering a particular set of modules (e.g. ELAC controls the ailerons and elevator, SEC controls spoilers and elevator). There's a more in-depth overview here: https://aviation.stackexchange.com/questions/47711/what-are-... . The autopilot is only one of them. The way they take over each other's functions is actually remarkably advanced, and leads to very interesting procedures for handling failures, see e.g. https://hursts.org.uk/airbus-nonnormal/html/ch05.html .

Now, on some airplanes, some actuators can only be controlled through these computers. They get the commands from the pilot and they issue the right signals that control the actuators. There's no way to bypass them. You can turn off the autopilot and the plane goes where you want but the actuators that control the flight control surfaces are still acted upon by computers.

I don't know if this is the case on Airbus specifically (like I said, I'm in a different field), but if it were, then simply turning those systems off in case of something unexpected is definitely not the right design solution.

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

#279

Post by wycy »

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…

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.

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

#280

Post by ChrisLomont »

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

http://www.cplusplus.com/reference/cstdio/printf/
Post reply on HN