34 ms·

Interestin things about Ada: - language designer have a document where they explain their choices, the Ada Rationale: http://www.ada-auth.org/standards/rationa

by guerby 5y ago

Interestin things about Ada: - language designer have a document where they explain their choices, the Ada Rationale: http://www.ada-auth.org/standards/rationale12.html http://www.ada-auth.org/standards/rationale12.html - there is an annotated version of the standard, and it's freely available as the standard: http://www.ada-auth.org/arm.html http://www.ada-auth.org/arm.html - A language test suite was developped at the same time of the language: https://en.wikipedia.org/wiki/Ada_Conformity_Assessment_Test_Suite https://en.wikipedia.org/wiki/Ada_Conformity_Assessment_Test... The last point was also in retrospect not sot good for the language ecosystem: buyers wanted a 100% on this test suite before considering your Ada compiler, which means dev had hundreds of compiler bugs to fix and no paying customers.

ChrisMarshallNY 5y ago
> dev had hundreds of compiler bugs to fix and no paying customers. From what I understand, a principal rationale of Ada, was to have a “100% reliable” toolchain, and compile-time assurance. So this is actually a reasonable posture. It seems that Ada can be challenging. In the 1980s, there was a project to rewrite the nation’s air traffic control system, in Ada (I knew a couple of engineers, working on it). I don’t think it ended well.
- topdancing 5y ago
  > I don’t think it ended well. https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html would suggest otherwise
  - ChrisMarshallNY 5y ago
    The US version flamed out, in spectacular fashion. The European one, however, worked. Another poster put up links ([0], [1]). [0] https://web.archive.org/web/20160601100527/http://www.bloomberg.com/news/articles/1993-04-25/flying-in-place-the-faas-air-control-fiasco https://web.archive.org/web/20160601100527/http://www.bloomb... (Unpaywalled) [1] https://www.skybrary.aero/index.php/Central_Flow_Management_Unit_(CFMU) https://www.skybrary.aero/index.php/Central_Flow_Management_... It wasn't a ding at Ada. However, big projects (regardless of the toolset) need to be well-managed.
    - egberts1 5y ago
      Sure wasn’t a ding against Ada. It appeared that mismanagement and misprioritization of the huge ATC wish list and a failure of system engineering to factor limited system resources … then to its priority list. A different US contractor (that I can’t recall) apparently did ATC better and faster but for a set of different customers (also in Ada). It must have been when “you don’t get fire for hiring IBM” was a mantra then.
      - Spooky23 5y ago
        I hate to defend IBM, but they did have a track record of building out massive systems like this. I’d guess the 80s political climate and more general incompetence at the agency and political level was a bigger issue than the vendors and integrators.
      - sparcpile 5y ago
        The program's name was AAS, the Advanced Automation System. It was designed to be a full end-to-end system replacement for the HOST mainframe systems that were the FAA's backbone. This included terminal, en-route, oceanic, and every other system that was managing aircraft. AAS is discussed as a failure because it had significant mission and requirements creep. FAA kept on piling on requirements and IBM kept saying yes. The FAA also had issues managing it because it was so large. It was a multi-billion program with millions of SLOC in the early 90s. Simply put, this was a not a cat video website. The tool suite was on AIX 3.2.5 running on RS/6000s using CMVC for source code management. This was all designed in the mid-80s with implementation starting in the late 80s through the mid 90s. AAS was originally designed after the mass firings of the ATC specialists and the shutdown of PATCO, the original ATC union. AAS was actually a entire suite of programs. AAS was overall program and funding vehicle. IBM Federal deployed a few of the sub-programs like ISSS, TCCC, and others successfully to the FAA. It was originally developed by IBM Federal Systems and deployed on then-new RS/6000s. AAS failed because of mission creep and the fact it was entirely too large. The program ended after IBM Federal Systems was sold off to Loral and then merged into Lockheed Martin. The head of the ATC group at the time, Bob Stevens, discovered that LM would make more money if FAA cancelled the project and split it up into much smaller programs. Bob called up the FAA Administrator and made the deal to cancel the program since the scope creep was too much. FAA had already sent out a couple of cure letters to get things back on track, but this time the FAA agreed that it was time to cut bait on it. Initially, what was the en-route portion of AAS was re-done as the Display System Replacement (DSR), which replaced the radar and data positions in the en-route facilities. The concepts of AAS were then rolled into NextGen, which is the FAA's family of programs to modernize its ATC systems. Ada was used (originally OC Systems's Ada83 and Ada95 PowerAda compilers) for everything in AAS. An Ada-based middleware called FlightDeck was developed to implement all the underlying libraries and subsystems that you need for highly available applications for AAS, including clustering, failover, heartbeats, monotonic time, and multiple levels of redundancy. That middleware is still being today for the systems that IBM Federal, Lockheed Martin, and now Leidos are maintaining and developing like ERAM. After LM bought out what was IBM Federal, they sold it off in 2015 to Leidos because LM wanted to focus more on hardware. (Source: I work on the later programs that Ada is used on and listened to all stories that were told me by the people who worked on AAS).
- synack 5y ago
  That ATC project failed for many reasons, mostly mismanagement. Flying In Place: The FAA's Air Control Fiasco https://www.bloomberg.com/news/articles/1993-04-25/flying-in-place-the-faas-air-control-fiasco https://www.bloomberg.com/news/articles/1993-04-25/flying-in... Meanwhile in Europe, Eurocontrol's CFMU (Central Flow Management Unit) is written in Ada and successfully routes thousands of flights a day.
  - throw0101a 5y ago
    > Meanwhile in Europe, Eurocontrol' s CFMU (Central Flow Management Unit) is written in Ada and successfully routes thousands of flights a day. Was this a new system, or a replacement of old code? If the latter, could that have been a complicating factor?
  - niea_11 5y ago
    If anyone is interested, here is "an experience report" (slides) about the use of Ada in Eurocontrol' s CFMU : https://slideplayer.com/slide/11313411/ https://slideplayer.com/slide/11313411/
    - todd8 5y ago
      The concluding slide from this report: > The Ada language is one of the factors which has helped to build, maintain and enhance the CFMU mission critical sophisticated applications.
    - agumonkey 5y ago
      glorious, thanks
  - touisteur 5y ago
    And I'd say out of the US the majority of ATC radars after 95 are probably running some mix of Ada and C.
- retrac 5y ago
  Canada's national air traffic control system is implemented in ~1 million lines of almost pure Ada, handling everything from the radars to the user interface. If non-C-family isn't a dealbreaker I would seriously consider Ada for a large project. Very strong typing and modularity that are very suited for large-scale development, a wide range of available toolchains, but without the kitchen sink. (But I'm not qualified to make such decisions.) Besides, something like implementation language is almost never why a very large software project fails. (Though if you're already failing, then e.g. implementing your cloud service in COBOL is probably not helping.) It's usually from mismanagement, or a failure to define or understand the problem appropriately.
- mbrodersen 5y ago
  Large projects usually fail because of politics/resources/… Not because of the programming language used. There are successful and failed large scale projects in almost any programming language.
mike_hock 5y ago
> The last point was also in retrospect not sot good for the language ecosystem: buyers wanted a 100% on this test suite before considering your Ada compiler, which means dev had hundreds of compiler bugs to fix and no paying customers. You mean, they couldn't sell a half-finished product while claiming "100% conformity"? Awesome.
- noir_lord 5y ago
  Especially given the markets Ada was used in.
- guerby 5y ago
  Compiler validation is done by a third party so you cannot claim validation without really passing the testsuite. All compilers have bugs and releases happen (at least for GCC which I know a bit more than others) with plenty of known open bugs. Having a testsuite is of course a good thing, however if you take the top 20 programming languages in use, how many of them do have an accepted wide coverage publically available language test suite? You said "half-finished product" but what about compiler for every other language than Ada of which most of them don't have a testsuite? How do buyer decide to use Intel C Compiler for example? Remember all of this was in early 1980. Having this testsuite was well ahead of its time as many things with Ada, what I'm trying to say is that it didn't play well at the time to help the language ecosystem grow.
  - orhmeh09 5y ago
    The purpose of Ada was not to sell compilers, nor to serve as a means for an acquihire, nor IPO, nor VC money. Passing the test suite is just about the most important thing an Ada compiler must do. The requirements of the language originate here: http://iment.com/maida/computer/requirements/strawman.htm#si.f.4 http://iment.com/maida/computer/requirements/strawman.htm#si... > Every user level aspect of the language will be formally specified. None will be left to the translator implementer, operating system or object machine. > There will be a traceable operational and/or technological requirement for each primitive data, operation and control structure in the language. > The language will not reveal minor differrences in computer architecture. > Machine dependent code cannot appear interspersed in-line in source language programs. > The semantics of the language will be determinable from the description. > Constructs of the language will have only one reasonable interpretation (i.e., physcologically unambiguous). > There will be an axiomatic definition of the language. It will be mathematically complete in the Turing sense. > The language will not sacrifice clarity for efficiency. > The language will not contain special features for rare cases. > All defaults in a program will be specifically provided in the language specification or in the program. > There will be a minimal number of defaults. … > Any translator for the language must implement the entire language (NO subsets). > Any translator for the language must implement only the language as specified (translator implementer may not expand the language specification). > Translator does not have to run on all object machines. Self-hosting is not required. These are the requirements Ada was designed to fulfill. If not passing the test suite is OK with you, you probably have no use for Ada and would be better served by another language. This is the best you can hope for in sensitive applications like aviation. I would feel better knowing the software flying me was extensively validated.
zetalyrae 5y ago
I think every language should have a design rationale. I'm working on the spec for my programming language, and I intend the rationale to be >50% of the size of the spec. It's great because it allows me to justify every facet of the language as part of a cohesive whole.
- ghoward 5y ago
  I think this is a good idea. I'm also designing a language, and I have the rationale sort of written, but scattered amongst many design documents. I should put it all in one place like you.

by guerby 5y ago

ChrisMarshallNY 5y ago

> dev had hundreds of compiler bugs to fix and no paying customers. From what I understand, a principal rationale of Ada, was to have a “100% reliable” toolchain, and compile-time assurance. So this is actually a reasonable posture. It seems that Ada can be challenging. In the 1980s, there was a project to rewrite the nation’s air traffic control system, in Ada (I knew a couple of engineers, working on it). I don’t think it ended well.

topdancing 5y ago
> I don’t think it ended well. https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html would suggest otherwise
- ChrisMarshallNY 5y ago
  The US version flamed out, in spectacular fashion. The European one, however, worked. Another poster put up links ([0], [1]). [0] https://web.archive.org/web/20160601100527/http://www.bloomberg.com/news/articles/1993-04-25/flying-in-place-the-faas-air-control-fiasco https://web.archive.org/web/20160601100527/http://www.bloomb... (Unpaywalled) [1] https://www.skybrary.aero/index.php/Central_Flow_Management_Unit_(CFMU) https://www.skybrary.aero/index.php/Central_Flow_Management_... It wasn't a ding at Ada. However, big projects (regardless of the toolset) need to be well-managed.
  - egberts1 5y ago
    Sure wasn’t a ding against Ada. It appeared that mismanagement and misprioritization of the huge ATC wish list and a failure of system engineering to factor limited system resources … then to its priority list. A different US contractor (that I can’t recall) apparently did ATC better and faster but for a set of different customers (also in Ada). It must have been when “you don’t get fire for hiring IBM” was a mantra then.
    - Spooky23 5y ago
      I hate to defend IBM, but they did have a track record of building out massive systems like this. I’d guess the 80s political climate and more general incompetence at the agency and political level was a bigger issue than the vendors and integrators.
    - sparcpile 5y ago
      The program's name was AAS, the Advanced Automation System. It was designed to be a full end-to-end system replacement for the HOST mainframe systems that were the FAA's backbone. This included terminal, en-route, oceanic, and every other system that was managing aircraft. AAS is discussed as a failure because it had significant mission and requirements creep. FAA kept on piling on requirements and IBM kept saying yes. The FAA also had issues managing it because it was so large. It was a multi-billion program with millions of SLOC in the early 90s. Simply put, this was a not a cat video website. The tool suite was on AIX 3.2.5 running on RS/6000s using CMVC for source code management. This was all designed in the mid-80s with implementation starting in the late 80s through the mid 90s. AAS was originally designed after the mass firings of the ATC specialists and the shutdown of PATCO, the original ATC union. AAS was actually a entire suite of programs. AAS was overall program and funding vehicle. IBM Federal deployed a few of the sub-programs like ISSS, TCCC, and others successfully to the FAA. It was originally developed by IBM Federal Systems and deployed on then-new RS/6000s. AAS failed because of mission creep and the fact it was entirely too large. The program ended after IBM Federal Systems was sold off to Loral and then merged into Lockheed Martin. The head of the ATC group at the time, Bob Stevens, discovered that LM would make more money if FAA cancelled the project and split it up into much smaller programs. Bob called up the FAA Administrator and made the deal to cancel the program since the scope creep was too much. FAA had already sent out a couple of cure letters to get things back on track, but this time the FAA agreed that it was time to cut bait on it. Initially, what was the en-route portion of AAS was re-done as the Display System Replacement (DSR), which replaced the radar and data positions in the en-route facilities. The concepts of AAS were then rolled into NextGen, which is the FAA's family of programs to modernize its ATC systems. Ada was used (originally OC Systems's Ada83 and Ada95 PowerAda compilers) for everything in AAS. An Ada-based middleware called FlightDeck was developed to implement all the underlying libraries and subsystems that you need for highly available applications for AAS, including clustering, failover, heartbeats, monotonic time, and multiple levels of redundancy. That middleware is still being today for the systems that IBM Federal, Lockheed Martin, and now Leidos are maintaining and developing like ERAM. After LM bought out what was IBM Federal, they sold it off in 2015 to Leidos because LM wanted to focus more on hardware. (Source: I work on the later programs that Ada is used on and listened to all stories that were told me by the people who worked on AAS).
synack 5y ago
That ATC project failed for many reasons, mostly mismanagement. Flying In Place: The FAA's Air Control Fiasco https://www.bloomberg.com/news/articles/1993-04-25/flying-in-place-the-faas-air-control-fiasco https://www.bloomberg.com/news/articles/1993-04-25/flying-in... Meanwhile in Europe, Eurocontrol's CFMU (Central Flow Management Unit) is written in Ada and successfully routes thousands of flights a day.
- throw0101a 5y ago
  > Meanwhile in Europe, Eurocontrol' s CFMU (Central Flow Management Unit) is written in Ada and successfully routes thousands of flights a day. Was this a new system, or a replacement of old code? If the latter, could that have been a complicating factor?
- niea_11 5y ago
  If anyone is interested, here is "an experience report" (slides) about the use of Ada in Eurocontrol' s CFMU : https://slideplayer.com/slide/11313411/ https://slideplayer.com/slide/11313411/
  - todd8 5y ago
    The concluding slide from this report: > The Ada language is one of the factors which has helped to build, maintain and enhance the CFMU mission critical sophisticated applications.
  - agumonkey 5y ago
    glorious, thanks
- touisteur 5y ago
  And I'd say out of the US the majority of ATC radars after 95 are probably running some mix of Ada and C.
retrac 5y ago
Canada's national air traffic control system is implemented in ~1 million lines of almost pure Ada, handling everything from the radars to the user interface. If non-C-family isn't a dealbreaker I would seriously consider Ada for a large project. Very strong typing and modularity that are very suited for large-scale development, a wide range of available toolchains, but without the kitchen sink. (But I'm not qualified to make such decisions.) Besides, something like implementation language is almost never why a very large software project fails. (Though if you're already failing, then e.g. implementing your cloud service in COBOL is probably not helping.) It's usually from mismanagement, or a failure to define or understand the problem appropriately.
mbrodersen 5y ago
Large projects usually fail because of politics/resources/… Not because of the programming language used. There are successful and failed large scale projects in almost any programming language.

mike_hock 5y ago

> The last point was also in retrospect not sot good for the language ecosystem: buyers wanted a 100% on this test suite before considering your Ada compiler, which means dev had hundreds of compiler bugs to fix and no paying customers. You mean, they couldn't sell a half-finished product while claiming "100% conformity"? Awesome.

noir_lord 5y ago
Especially given the markets Ada was used in.
guerby 5y ago
Compiler validation is done by a third party so you cannot claim validation without really passing the testsuite. All compilers have bugs and releases happen (at least for GCC which I know a bit more than others) with plenty of known open bugs. Having a testsuite is of course a good thing, however if you take the top 20 programming languages in use, how many of them do have an accepted wide coverage publically available language test suite? You said "half-finished product" but what about compiler for every other language than Ada of which most of them don't have a testsuite? How do buyer decide to use Intel C Compiler for example? Remember all of this was in early 1980. Having this testsuite was well ahead of its time as many things with Ada, what I'm trying to say is that it didn't play well at the time to help the language ecosystem grow.
- orhmeh09 5y ago
  The purpose of Ada was not to sell compilers, nor to serve as a means for an acquihire, nor IPO, nor VC money. Passing the test suite is just about the most important thing an Ada compiler must do. The requirements of the language originate here: http://iment.com/maida/computer/requirements/strawman.htm#si.f.4 http://iment.com/maida/computer/requirements/strawman.htm#si... > Every user level aspect of the language will be formally specified. None will be left to the translator implementer, operating system or object machine. > There will be a traceable operational and/or technological requirement for each primitive data, operation and control structure in the language. > The language will not reveal minor differrences in computer architecture. > Machine dependent code cannot appear interspersed in-line in source language programs. > The semantics of the language will be determinable from the description. > Constructs of the language will have only one reasonable interpretation (i.e., physcologically unambiguous). > There will be an axiomatic definition of the language. It will be mathematically complete in the Turing sense. > The language will not sacrifice clarity for efficiency. > The language will not contain special features for rare cases. > All defaults in a program will be specifically provided in the language specification or in the program. > There will be a minimal number of defaults. … > Any translator for the language must implement the entire language (NO subsets). > Any translator for the language must implement only the language as specified (translator implementer may not expand the language specification). > Translator does not have to run on all object machines. Self-hosting is not required. These are the requirements Ada was designed to fulfill. If not passing the test suite is OK with you, you probably have no use for Ada and would be better served by another language. This is the best you can hope for in sensitive applications like aviation. I would feel better knowing the software flying me was extensively validated.

zetalyrae 5y ago

I think every language should have a design rationale. I'm working on the spec for my programming language, and I intend the rationale to be >50% of the size of the spec. It's great because it allows me to justify every facet of the language as part of a cohesive whole.

ghoward 5y ago
I think this is a good idea. I'm also designing a language, and I have the rationale sort of written, but scattered amongst many design documents. I should put it all in one place like you.