This article promotes a popular misconception of the programming situation for defense projects in the 1970s. There may have been "hundreds of specialized programming languages" in existence that could be used, but just a handful actually predominated. Most aeronautical projects were done in JOVIAL.<p>I've talked about this history with engineers from the 1960s-70s. They did not regard the introduction of Ada as a good thing. The JOVIAL language had been developed by engineers and modified through experience over several years to become something they were quite happy with. The impetus that led to Ada came from management and implementation was done by academics.
I live near Sydney University ( not my alma-mater ). In a rather serendipitous turn, one day on my way home from the shops I was walking past one of the USYD buildings and there was a giant stack of library books that had thrown out onto the sidewalk as rubbish to be collected by the council.
It turns out they were old science faculty books that were no longer prescribed material. I started looking through them and found several books on Safety-critical software development in Ada, several books on hardware design and several others on software development. I took them all home, at first thinking the Ada ones would just be some archaic novelty. When I got a chance to read them I was amazed. I was expecting something akin to COBOL from the language. Instead I found a language that was extremely well designed for its domain. I'd already done a bit of embedded and operating system development, and I could immediately see how Ada would benefit a developer in these areas. Even representation clauses alone are such a huge convenience for low-level programming.
I haven't looked back since. I was actually in the process of preparing a bare-bones example of operating system development in Ada, if this post had been three days later I'd have been able to link the finished product here right now.
There is some overlap in the use cases between Ada-in-the-mainstream (which seems to be what the article is suggesting) and Rust. The existence of Rust will make it even harder for Ada to break out of its existing domains.<p>Both seem to have good ecosystems, but quite different. Ada has more high-assurance tooling and practices. Rust has more in terms of packaging and general-purpose high level libraries.<p>With Ada, it's pretty hard to shake the feeling that it's not as welcoming. Either you are building a spacecraft, or "what are you doing here?". Not that anyone actually says that, and in my limited experience playing with the language, everyone seemed nice. It's just a feeling that's hard to escape. I wish it weren't so, because I think Ada has a lot going for it and it could be good in more donains.<p>One kind of cool thing is that it's designed to get by without so many heap allocations, and it does some interesting things to allow/encourage more stack allocations. It also has more sophisticated runtime checks, like contracts, that are kind of between a unit test and a compile-time check.<p>Rust is great at managing complexity. I keep holding out hope that Ada can somehow give us some simplicity back while still making useful software.
> Ada code controls rockets like the Ariane 4 and 5, many satellites, and countless other systems where small glitches can have major consequences.<p>A somewhat amusing endorsement given that the infamous failure of the maiden launch of the Ariane 5 due to series of interconnected software bugs - a reminder perhaps that the choice of implementation language does not automatically make for a reliable system.
Ada was the language of the undergraduate curriculum at the University of Washington when I was there (late 1980's) -- because Boeing. One of the core safety mechanisms was exception handling.<p>* The biggest thing I miss is that <i>every</i> block was inherently a try-block. Just put your exception handlers at the bottom of the block. This provided a nice separation of "normal flow-control" and "exceptional flow-control". Why have try-catch anyway -- I never got used to that later in life.<p>* Exceptions were not synonymous with errors. In fact the way to read a file byte by byte was just to keep reading bytes and never explicitly check for end-of-file. Let the exception handler handle this case. Logic is much cleaner.<p>* Remember that you can't just dump core and shell out to the OS on an un-handled exception -- not if your controlling a ICBM flying of the continent. Ada really forced you to handle all errors at some level of the call-stack with an exception handler. At the outer-most level -- just call self-destruct.
If you've done VHDL, you'll be familiar with Ada's syntax. When the DoD commissioned the design of VHDL, they required that its syntax be based on Ada.<p><a href="https://en.wikipedia.org/wiki/VHDL#History" rel="nofollow">https://en.wikipedia.org/wiki/VHDL#History</a>
I've developed a set of "strongly typed" classes in C++ that have saved me a ton of grief.<p>Here are some examples. All classes are fundamentally floats. Errors are caught at compilation.<p><pre><code> cInches i1, i2, i3;
cCm cm1, cm2;
i1 = 1.f; // error
i1 = cInches(1.f); // OK
i3 = i1 + i2; // OK
cm1 = i1; // error
i1 = i2 * 2.f; // OK
float f1 = i1 / i2; // OK
i1 = i2 * i3; // error! square inches are not inches
int add(cInches in1, cInches in2);
add(i1, i2); // OK
add(cm1, cm2); // error
</code></pre>
'Typedef's just don't cut it.
First, this is a great introduction article to Ada. It's a great history lesson, and analysis of where it's used and why.<p>That said, it seems to be arguing for something in a vacuum. Where is the mention of other new programming languages that also fit this category? Where is the mention of Rust? Rust fits all the same requirements:<p>- A general, flexible design that adapts to satisfy the needs of embedded computer applications.<p>- Reliability. The language should aid the design and development of reliable programs.<p>- Ease of maintainability. Code should be readable and programming decisions explicit.<p>- Easy to produce efficient code with. Inefficient constructs should be easily identifiable.<p>- No unnecessary complexity. Semantic structure should be consistent and minimize the number of concepts.<p>- Easy to implement the language specification. All features should be easy to understand.<p>- Machine independence. The language shall not be bound to any hardware or OS details.<p>- Complete definition. All parts of the language shall be fully and unambiguously defined.<p>The exception is possibly the last one, complete definition. But that's debatable as Rust does have a reference, but no one wants to go as far as calling it a spec. (Also, I know some people think Rust has some "unnecessary" complexity, personally I do not). The article goes on to compare to C, but doesn't mention some of the new features of C++ that make it safer, or Rust which is approximately as safe as Ada. So why would I pick Ada over other modern languages?<p>btw, I really enjoyed Steve Klabnik's post on learning Ada: <a href="https://words.steveklabnik.com/learning-ada" rel="nofollow">https://words.steveklabnik.com/learning-ada</a>
I first read about Ada in JARGON:<p><pre><code> Ada:: n. A {{Pascal}}-descended language that has been made
mandatory for Department of Defense software projects by the
Pentagon. Hackers are nearly unanimous in observing that,
technically, it is precisely what one might expect given that kind
of endorsement by fiat; designed by committee, crockish, difficult
to use, and overall a disastrous, multi-billion-dollar boondoggle
(one common description is "The PL/1 of the 1980s"; hackers find
the exception handling and inter-process communication features
particularly hilarious). Ada Lovelace (the daughter of Lord Byron
who became the world's first programmer while cooperating with
Babbage on the design of his mechanical computing engines in the
mid-1800s) would almost certainly blanch at the use her name has
been latterly put to; the kindest thing that has been said about it
it is that there is probably a good small language screaming to get
out from inside its vast, {elephantine} bulk.
</code></pre>
Maybe the situation is different now?
I'm missing SPARK, the restricted and formally defined language based on Ada, extending Ada with contracts and aspects, and disallowing the insecure parts.
<a href="https://en.wikipedia.org/wiki/SPARK_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/SPARK_(programming_language)</a>
This is the real highlight of Ada.
As a side note for people like me who have no option other than C for their safety critical projects, remember there's a MISRA-C standard. If that feels too much, [1] is a good starting point.<p>[1] <a href="http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf" rel="nofollow">http://pixelscommander.com/wp-content/uploads/2014/12/P10.pd...</a>
What about Forth?<p>I quite like the way it eschews too much abstraction and can go from very low level to high level with a lot less code (and less bugs).<p>Given the current interest with IoT and the proliferation of cheap micro controllers it might be due for a resurgence(?).
I used Ada (GNAT) about 15 years ago. One of the things that struck me was the accuracy of the compiler error messages and the sophistication of the debugger, when compared to C/C++ in Visual Studio / GCC
This article was a decent introduction, I suppose. I've been learning Ada for about a year now, and I quite like it. It's larger than the previously largest language I know, Common Lisp, but I like the focus on reliability and whatnot; it's a language that has many facilities programs need, but you don't need to use otherwise; it's also segmented well, unlike Common Lisp, but there's advantages to both methods.<p>There's a flaw in the article:<p><i>Ada doesn't define standard types like int or float</i>...<p>It does, technically, Integer and Float. The rest of the article is fine.<p>Lastly, it's amusing to see the Rust advocates cry out due to this. As I like to write, Ada is used in critical systems such as ballistic missiles and trains, whereas Rust is used in Firefox.
During weekend installfest/hackfest events at a LUG that I used to attend, there was always this one guy who would sit in front of a pair of laptops and code in Ada.
One thing I remember about it is just how much it reminded me of Pascal.
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.
I once flipped through Ada spec (purely voluntarily) and in my opinion it was a really well designed language. I generally come to believe that a language should offer fewer fancy programming constructs, but advance in specifications and definitions, and Ada looked like a solid step in that direction (as compared to C, for example). As it was recently pointed out by some other discussion here at HN the idea of software development is to document knowledge, and Ada is pretty good at that. The modern trend is very different, unfortunately.
No you shouldn't be writing in Ada. Embedded software running all kinds of sensitive workloads, from pacemakers to routers/switches use C for it's superior tooling, universal support across compilers and chip vendors, massive user base and decades long best practices (like NASA's C coding guidelines) to mitigate some of C's potential inadvertent misuses.<p>Not to mention the bevy of advanced niche features, like SIMD support, and custom GCC extensions that lend superpowers to C coders that other languages typically lack.<p>Sure, ada may have it's benefits for certain narrow use cases, but for non-hobby projects spanning tens/hundreds of engineers, considering real world vendor support for ada and missing talent pool, C is the obvious choice