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

301–310 of 330 posts

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

#301

Post by xaedes »

ff317 wrote: post #289
wycy wrote: post #279

Earlier quoted context omitted.

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

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

Brings to my mind: Erlang

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

#302

Post by shakna »

kazinator wrote: post #300
shakna wrote: post #290

Earlier quoted context omitted.

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)

That's an awful amount of boilerplate for a simple integer hello world. Languages with these modules and import statements should be burned. (Starting with Python.) For pete's sake, couldn't they at least combine this with and use into one keyword so you don't have to repeat yourself? Or can't use be made to forgive a missing with and just get on with the show? Do defense contracts pay by the byte or what?

'use' allows you to integrate namespaces, that's all. You can have multiples of those within the same file. Not all 'with' statements will only expose a single namespace.

Nothing different than std in C++.

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

#303

Post by kazinator »

shakna wrote: post #302
kazinator wrote: post #300

Earlier quoted context omitted.

That's an awful amount of boilerplate for a simple integer hello world. Languages with these modules and import statements should be burned. (Starting with Python.) For pete's sake, couldn't they at least combine this with and use into one keyword so you don't have to repeat yourself? Or can't use be made to forgive a missing with and just get on with the show? Do defense contracts pay by the byte or what?

'use' allows you to integrate namespaces, that's all. You can have multiples of those within the same file. Not all 'with' statements will only expose a single namespace. Nothing different than std in C++.

C++ is awful also; it is not a good choice of benchmark for brevity.

Though a single use declaration will get you the identifier in C++, the right header file has to be #included. At least it's possible for a single include to bring in lots of material:

  #include   // just one of these

  use bigfoo::bar;   // one per identifier
  use bigwidget::zark;
But C++ has lots of irritating repetition like:

  class foo {
    foo();
    ~foo();
  };

  foo::foo()
  {
  }

  foo::~foo()
  {
  }
Seven repetitions of foo just to set up an empty class skeleton with non-inlined constructor and destructor.

(The C++ people are self-conscious about verbosity, and trying to fix the problem; unfortunately, in wrongheaded ways that are making the language worse.)

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

#304

Post by deathtrader666 »

xaedes wrote: post #301
ff317 wrote: post #289

Earlier quoted context omitted.

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

"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" Brings to my mind: Erlang

Was waiting for someone to mention Erlang.

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

#305

Post by shakna »

kazinator wrote: post #303
shakna wrote: post #302

Earlier quoted context omitted.

'use' allows you to integrate namespaces, that's all. You can have multiples of those within the same file. Not all 'with' statements will only expose a single namespace. Nothing different than std in C++.

C++ is awful also; it is not a good choice of benchmark for brevity. Though a single use declaration will get you the identifier in C++, the right header file has to be #included. At least it's possible for a single include to bring in lots of material: #include // just one of these use bigfoo::bar; // one per identifier use bigwidget::zark; But C++ has lots of irritating repetition like: class foo { foo(); ~foo(); }…

I'm not sure brevity is a benchmark for a good language either.

So far as I can tell, you dislike how verbose the Ada "hello world" is, because it supports namespaces, and uses them. That wouldn't be something I'd agree with, especially not when dealing with any program of significant size.

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

#306

Post by alexeiz »

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…

> this is Ada, so it caused an integer overflow exception

This is not a language issue, but a general engineering one. In any critical system that can cause an unexpected exception and failure, there should be sufficient redundancy, so that when the main system goes down, the failover system can take control.

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

#307

Post by Gibbon1 »

swsieber wrote: post #154
atoav wrote: post #113

Earlier quoted context omitted.

Another consideration: Rust’s compiler is also slower because it does a lot more forces you to add error handling. In terms of real impact on developers I never felt it was dramatic. The rust language support in editors is so good that you will catch most errors before compiling. So once everything is dealt with you usually compile and it just works. Binary size is also one of these areas they are dealing with atm.

It's also slower because it hands LLVM a boat-load of IR and relies on LLVM to optimize it (instead of doing it itself).

I've heard this is mostly the answer. Which makes me assume that the LLVM is a bad match for rust's backend requirements.

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

#308

Post by kragen »

blub wrote: post #283
kragen wrote: post #221

Earlier quoted context omitted.

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?

We have a lot of experience with floating-point qNaN values since IEEE 488 introduced them in 1985, and more rigorous languages than Ada — such as OCaml, Haskell, and Rust — use a generalized version of the concept for a lot of error handling.

I don't think there's an open-and-shut case that error values are "preferred or beneficial" in general with respect to exception handling through nonlocal control-flow transfers; there are reasonable arguments on both sides, and it seems likely that both are viable options in most circumstances, and which is better depends on those circumstances. (For example, lazy evaluation or catastrophic consequences attached to software crashes would seem to me to weigh heavily on the side of using error values, while interactive REPL-style usage would seem to me to weigh on the side of nonlocal control flow, perhaps with Common-Lisp-style restarts.)

My point was narrower: in this particular case, using error values analogous to NaNs, rather than shutting down the SRI, would have saved the rocket, without posing the risk of using garbage data that C's semantics pose. In this particular case, they would have been better. It's possible that, in other cases, perhaps even in other places in the SRI firmware, using error values would have been worse than unwinding the stack or shutting down the SRI. But in this case they would have been better.

(If you aren't convinced of that narrow point, you should probably read the report from the Lions board of inquiry.)

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

#309

Post by Supermancho »

shakna wrote: post #305
kazinator wrote: post #303

Earlier quoted context omitted.

C++ is awful also; it is not a good choice of benchmark for brevity. Though a single use declaration will get you the identifier in C++, the right header file has to be #included. At least it's possible for a single include to bring in lots of material: #include // just one of these use bigfoo::bar; // one per identifier use bigwidget::zark; But C++ has lots of irritating repetition like: class foo { foo(); ~foo(); }…

I'm not sure brevity is a benchmark for a good language either. So far as I can tell, you dislike how verbose the Ada "hello world" is, because it supports namespaces, and uses them. That wouldn't be something I'd agree with, especially not when dealing with any program of significant size.

> I'm not sure brevity is a benchmark for a good language either.

It's the only benchmark that we have any kind of analysis for (https://www.researchgate.net/publication/3188171_The_Confoun...), which correlates to less defects and less time per feature. Less code is better. Until I see evidence to the contrary, I think it's a valid criticism. YMMV

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

#310

Post by shakna »

Supermancho wrote: post #309
shakna wrote: post #305

Earlier quoted context omitted.

I'm not sure brevity is a benchmark for a good language either. So far as I can tell, you dislike how verbose the Ada "hello world" is, because it supports namespaces, and uses them. That wouldn't be something I'd agree with, especially not when dealing with any program of significant size.

> I'm not sure brevity is a benchmark for a good language either. It's the only benchmark that we have any kind of analysis for ( https://www.researchgate.net/publication/3188171_The_Confoun... ), which correlates to less defects and less time per feature. Less code is better. Until I see evidence to the contrary, I think it's a valid criticism. YMMV

I agree with less code, but the tokens themselves needing to be shorter, not so much - so long as they remain easily readable.
Post reply on HN