8 ms·

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 instan

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 correctness to the avionics domain.

na85 7y ago
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 massive household name, I think its designers were vindicated by history.
- galangalalgol 7y ago
  Wasn't the ill fated code itself written in Ada? That is essentially all that goes on boeing aircraft. I don't think a lack of software engineering rigor is to blame for the design mistake.
  - na85 7y ago
    Possibly; I don't work for Boeing or their subcontractor. But I was getting at more of the general sense that as aircraft become more and more computerized we need more rigour and standardization of the sort that gave rise to Ada, and less of the aerospace equivalent of hacking things together in perl.
    - deleted 7y ago
      [deleted]
    - crucini 7y ago
      While I understand the instinct, there is a flip side. A while back Lutz Prechelt posed the phonecode problem, inviting solutions in multiple languages. While he didn't specify error handling, the Perl solutions were on average better at error handling than the compiled language solutions.
      - mk89 7y ago
        I think you are referring to [0]. Thanks a lot for sharing this, it's quite interesting! [0]: http://www.inf.fu-berlin.de/inst/ag-se/teaching/V-EMPIR-2011/14_quasi_experiment.pdf http://www.inf.fu-berlin.de/inst/ag-se/teaching/V-EMPIR-2011...
    - kragen 7y ago
      I would say we need more real rigor, of the kind that gave us qmail and seL4, and less fake rigor, of the kind that gave us Ada and inevitably proceeds from standardization. Standardization means less autonomy, which generally means that the opinions of prestigious people are imposed on everyone else. This can be good for intellectual rigor at first if your social pecking order is based on having sound opinions, like St. Augustine, but if it's based on anything else, standardization is an intellectual disaster from the start. And of course standardization prevents intellectual progress, always and everywhere, which is how Galileo ended up under house arrest.
- Skunkleton 7y ago
  The recent Boeing debacle was a systems engineering issue. AFAIU, there was a jammed sensor, and the systems corrected based on incorrect input from this sensor. Additionally, it is my understanding that some indicator that showed that these sensors disagreed with each other was not always present. Regardless, this entire incident was precipitated by boeing, and the carriers, not wanting to have to retrain pilots on the new systems.
- amluto 7y ago
  The Boeing debacle is an example of software performing exactly to specification. The spec was the problem.
- nwallin 7y ago
  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 that wouldn't have mattered because the code wasn't necessary during flight. It was an oversight that it was running at all.) However, this is Ada, so it caused an integer overflow exception. Which was uncaught. Which caused the entire system to nope out. Which caused the rocket to blow up. So there's that to consider.
  - ajxs 7y ago
    > "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 implemented the application.
    - admax88q 7y ago
      There is something to be said for not just halting on an error in production systems. Its the same reason assertions are usually turned off on production builds. Yes ideally the programmers should have handled the exception, but once your in production and the system is running, should you really just halt the whole program due to an exception the prograera didn't foresee?
      - vore 7y ago
        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, not to allow the program to plow through invariants being violated.
devnulloverflow 7y ago
> 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).
- shakna 7y ago
  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);
  - dawidw 7y ago
    printf is not c++
    - ChrisLomont 7y ago
      http://www.cplusplus.com/reference/cstdio/printf/ http://www.cplusplus.com/reference/cstdio/printf/
    - shakna 7y ago
      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.
  - bdavis__ 7y ago
    pakage int_io is new integer_io (num=>integer); and then int_io.putline(num);
    - shakna 7y ago
      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.3.7 https://www.adahome.com/LRM/83/RM/rm83html/lrm-14-03.html#14... (Ada 83 Manual)
AnIdiotOnTheNet 7y ago
> Many of the 'programmers' of those days lacked the sophistication and education to appreciate Ada. That certainly sounds like academic self-righteousness.

na85 7y ago

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 massive household name, I think its designers were vindicated by history.

galangalalgol 7y ago
Wasn't the ill fated code itself written in Ada? That is essentially all that goes on boeing aircraft. I don't think a lack of software engineering rigor is to blame for the design mistake.
- na85 7y ago
  Possibly; I don't work for Boeing or their subcontractor. But I was getting at more of the general sense that as aircraft become more and more computerized we need more rigour and standardization of the sort that gave rise to Ada, and less of the aerospace equivalent of hacking things together in perl.
  - deleted 7y ago
    [deleted]
  - crucini 7y ago
    While I understand the instinct, there is a flip side. A while back Lutz Prechelt posed the phonecode problem, inviting solutions in multiple languages. While he didn't specify error handling, the Perl solutions were on average better at error handling than the compiled language solutions.
    - mk89 7y ago
      I think you are referring to [0]. Thanks a lot for sharing this, it's quite interesting! [0]: http://www.inf.fu-berlin.de/inst/ag-se/teaching/V-EMPIR-2011/14_quasi_experiment.pdf http://www.inf.fu-berlin.de/inst/ag-se/teaching/V-EMPIR-2011...
  - kragen 7y ago
    I would say we need more real rigor, of the kind that gave us qmail and seL4, and less fake rigor, of the kind that gave us Ada and inevitably proceeds from standardization. Standardization means less autonomy, which generally means that the opinions of prestigious people are imposed on everyone else. This can be good for intellectual rigor at first if your social pecking order is based on having sound opinions, like St. Augustine, but if it's based on anything else, standardization is an intellectual disaster from the start. And of course standardization prevents intellectual progress, always and everywhere, which is how Galileo ended up under house arrest.
Skunkleton 7y ago
The recent Boeing debacle was a systems engineering issue. AFAIU, there was a jammed sensor, and the systems corrected based on incorrect input from this sensor. Additionally, it is my understanding that some indicator that showed that these sensors disagreed with each other was not always present. Regardless, this entire incident was precipitated by boeing, and the carriers, not wanting to have to retrain pilots on the new systems.
amluto 7y ago
The Boeing debacle is an example of software performing exactly to specification. The spec was the problem.
nwallin 7y ago
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 that wouldn't have mattered because the code wasn't necessary during flight. It was an oversight that it was running at all.) However, this is Ada, so it caused an integer overflow exception. Which was uncaught. Which caused the entire system to nope out. Which caused the rocket to blow up. So there's that to consider.
- ajxs 7y ago
  > "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 implemented the application.
  - admax88q 7y ago
    There is something to be said for not just halting on an error in production systems. Its the same reason assertions are usually turned off on production builds. Yes ideally the programmers should have handled the exception, but once your in production and the system is running, should you really just halt the whole program due to an exception the prograera didn't foresee?
    - vore 7y ago
      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, not to allow the program to plow through invariants being violated.

devnulloverflow 7y ago

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

shakna 7y ago
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);
- dawidw 7y ago
  printf is not c++
  - ChrisLomont 7y ago
    http://www.cplusplus.com/reference/cstdio/printf/ http://www.cplusplus.com/reference/cstdio/printf/
  - shakna 7y ago
    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.
- bdavis__ 7y ago
  pakage int_io is new integer_io (num=>integer); and then int_io.putline(num);
  - shakna 7y ago
    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.3.7 https://www.adahome.com/LRM/83/RM/rm83html/lrm-14-03.html#14... (Ada 83 Manual)

AnIdiotOnTheNet 7y ago

> Many of the 'programmers' of those days lacked the sophistication and education to appreciate Ada. That certainly sounds like academic self-righteousness.