I received the green postcard announcing that "Ada is Green", meaning that of the four candidates for Ada, the Green design had won. That was a long time ago.
The big problem in the early days was getting a compiler. DoD had a test suite for the compiler, and only compilers that passed could use the Ada name. They also had a "floor equals ceiling" rule - no missing features, no extra features. Compilers were to be feature-compatible.
That's how aerospace does things. The interface spec defines the interface. If something is incompatible with the interface, it's defective. It's why you can take Pratt and Whitney engines off a 767 and put on GE or Rolls Royce engines. DoD took the position that a compiler was a part with a specification.
Ada was a big language back then, and some of the compiler companies underestimated the job. Ada compilers were quite expensive - one for the M68000 was $40,000. I ordered that one when I was with a big aerospace company. When it showed up as a magnetic tape, it came with an unexpected cover letter, saying that this wasn't a validated compiler, and the validated compiler would follow - someday. No go. Quality control reject. Red tag attached: "REJECTED BY INCOMING INSPECTION - DOES NOT CORRESPOND TO SPECIFICATION". Purchase order says "validated compiler". Tape returned to vendor. Vendor tries to get out of giving refund. Legal department hammers vendor until they pay up. Meanwhile, another vendor ships a validated compiler, and that is ordered and used. That's how aerospace used to do things.
The compiler price was a big problem for non-Government customers. That contributed to the lack of adoption. We had great hopes for Ada, having used Modula successfully. But it was not to be.
I might be completely wrong here, but I get the feeling that thanks to the rising costs[0] of writing software in C and C++, alongside the availability of more approachable Ada compilers, its use has been raising.
At least it is a common presence at high integrity systems conferences, and being used in medical devices, avionics, robotics and train control systems.
From what I have been seeing at FOSDEM every year. AdaCore even had the opening keynote a few years back.
[0] bug fixing exploits, memory sanity tooling, research to improve the language, hardware changes (e.g. Intel MPX)
Yes, and those non-validated compilers, and even the validated ones, had lots of bugs. We had to get legal with a compiler vendor because of the number of bugs. This took disassembling the compiler on our end to prove our points.
"Ada is safe". Yes, if it outputs correct code. Otherwise, not so much. Lives were at stake here, and like you say, I'm not sure all the vendors were prepared for what that meant in terms of their product.
I really enjoyed working with Ada, but don't think I would want to go back to it today.
This is true to this day per IRONSIDES paper [1]. Made me consider using Ada as an executable specification language to be converted to equivalent C/C++ and compiled that way. They need to just do a functional implementation of the compiler in a language such as Ocaml with extensive testing. That's what Esterel did for SCADE generator. They said Ocaml compiler stages were easy to trace down to object code. So, that helps with the chicken and egg problem a bit. Alternatively, implement it in the VLISP, PreScheme, or VeriML that were formally verified for correctness.
Interestingly, languages such as Rust are still trying to accomplish the combination of efficiency and performance Ada has been doing for decades. Meanwhile, Ada developers (esp at AdaCore) haven't stood still: Design by Contract, provable absence of certain errors in SPARK code, more programming in the large support, zero-runtime deployment options, web app support, separation kernel runtimes for highest security, and more.
So, it might be a verbose, old language. It might not support the latest 1,000 fads in IT. Yet, here is a language designed in the 80's that does what modern systems languages are attempting to do, does it well, and has great tool support. So, I'd say the case for using Ada is long-made and companies doing mission-critical software have plenty reason to try to use it. Just try a project or two to see its benefits, at the least.
I have to add that verbosity serves a purpose here. Programming in the large often means those systems are long-living and the teams programming and maintaining them are huge, heterogeneous (in skill), and changing (esp. if it's a system running for decades). The verbosity comes from making many things pretty explicit and clear.
Ada is not made for explorative hacking or intellectual workouts but for reliable implementation. And it's not that those who criticize its verbosity program in APL themselves. ;)
> Programming in the large often means those systems are long-living and the teams programming and maintaining them are huge, heterogeneous (in skill), and changing (esp. if it's a system running for decades). The verbosity comes from making many things pretty explicit and clear.
I would say that this is the rule, rather than the exception, in software, and the fact that languages designed for "explorative hacking or intellectual workouts" eventually make it into production is simply a matter of inexperienced, though bright, developers prioritizing initial development cost over maintenance cost (which makes sense in startups, but those are a tiny minority of the industry). The average production codebase lifespan is about a decade, probably more.
I also agree that verbosity (up to a reasonable point) assists in maintaining codebases over time.
Which I recently came across looking for some simple Ada examples. It's verbose in the sense that there are fewer shortcuts -- you can't just read bytes, assume they convert to integers, and be done with it -- but in production you don't really want that anyway. Of course, doing what you should, rather than doing what you can get away with, will mean that when an engineer says "one week", and you multiply with two, for actual time of "two weeks" -- you'll have to multiply that again, for actual-for-reals, interface-actually-covers-the-bare-bones-we-need, of "four weeks"...
@jk4930, e12e I agree with both of you for the reasons for much of its verbosity and justification for that. One thing you two might have missed, in Safe Syntax chapter of my link, is that many verbose commands are designed so a single-letter typo causes compile failure rather than causes runtime error. Brilliant move I'd have never thought of doing.
Yet, there are readable, robust languages without a lot of verbosity. The question is what is the right balance. I show here [1] an alternative syntax to one of code examples in e12e's link that I believe is more readable while conveying the same thing. Shows room for improvement even in Ada's fundamentals. Note that I know Ada has several different I/O's on purpose but basic choices can often be inferred through types. Specifying such a core feature shouldn't be necessary except in unusual cases.
A minor point: I found the references to "Ada 1.0", "Ada 2.0", "Ada 3.0", and "Ada 4.0" distracting. I worked with Ada for a long time, and I've never heard of those terms. The successive language standards are almost universally referred to by the years they were published (1983, 1995, 2005, and 2012).
I agree and think it's slightly major. It's hard enough to get word on this language out. Having people Google for Ada 3.0 or 4.0 to get confusing results might make people say screw it. The author should revise the paper with the proper names for the sake of those people.
I would like to highlight that the first validated Ada language processor from 1983, the NYU Ada/Ed interpreter is still missing, along with its associated toolchain (an early SETL compiler for VAX/VMS implemented in a FORTRAN-like language known as LITTLE), more details are on my webpage:
There are also several other interesting or unusual Ada compilers still to be found too, notably:
Ada for the Intel iAPX-432 (arguably an instruction set architecture tailored to Ada)
Symbolics Ada - an Ada implemented in Lisp
Ada for the inmos Transputer - an Ada for a parallel computer architecture
I'm one of those people that think LISP is the most powerful language ever designed. Best for exploratory programming. Ada is best for mission-critical stuff being among the safest. While LISP didn't mainstream, Python did by emulating the right aspects of LISP without its issues. Coverity reported it had an extremely low defect rate, too. It's also great for maintainable, fairly-reliable, productive code. Yet, most installs still depend on unsafe code in interpreter and libraries.
So, what do you people think about doing a Python implementation in a combo of Ada and SPARK? Everything is done using robust, structured programming style with Design by Contract and all checks enabled by default. A given set of checks can be disabled if SPARK or another tool proves absence of that problem. Ada's tasking or (even better) the SCOOP model can give it real concurrency. The standard library features can be as safe or fast as necessary with Ada-grade interface protections and typing. OS-specific details will be abstracted away in order to port it to a low-TCB, microkernel OS or MirageOS-style Xen guest in the future.
The result should be as usable as Python, work about as fast, be more maintainable, and have fewer implementation risks. I'd also probably implement one of the Python compilers in Ada for performance boosts. Anyone think this is a project worth pushing on academics or FOSS?
On page 4, I don't exactly follow how the problematic compilation model works (specifically the bit about the implementation approach). Can anyone explain what exactly it's saying?
"Compilers are required to enforce the language rules in the same manner for a program consisting of several compilation units (and subunits) as for a program submitted as a single compilation. Consequently, a library file containing information on the compilation units of the program library must be maintained by the compiler or compiling environment."
How can i learn Ada as a student, when the compiler and IDE tooling is still so expensive? I want to learn it. Seems impossible without joining the army or similar 😠
I disagree with many things he writes. For example, safety in a language has never and will never come from particular language constructs. In the best case, we can isolate particular pieces of the program and look for counterexamples that will demonstrate that it does not work. That is why we use unit tests where applicable (where functions are at least idempotent). His concept of language safety is therefore spurious. There is simply no reason whatsoever to believe that a program in Ada would be safer than a program written in any other language. Safety is about validation and a program or a language cannot validate itself.
Furthermore, a programming language is something with a strong personality attached to it. Someone created it, because he felt like doing so and then you have other people who like it and feel like using it. Ada's language design committee did not qualify for that scenario.
By the way, could you imagine someone passionate about revolutionizing the world with his new idea that will defeat Facebook or so, writing his passionate ideas in Ada?
Seriously, nobody got the slightest enthusiastic about Ada and that is why Ada barely has any users at all. The language simply does not reflect what any user group would want to do. In other words, Ada has always been a solution desperately looking for a problem.
Ada has plenty of constructs to enhance safety. Explicit type conversion. Limited use of pointers. Arrays with bounds checking. No willy nilly 'enums are ints' type stuff. Contracts. Many more are covered here:
Plenty of people got interested in Ada. They are people that do things like write software for trains, nuclear reactors, medical devices, and aircraft. There's not much point in trying to use Ada for a website.
With that said, I always felt that the pitch for safety was always overstated. Of course tests are needed (not aware of any mission critical system where they aren't heavily used). There were lots of papers slamming things like C++ vs Ada back in the day. Yet we were able to do safe things in both languages. Guaranteeing things in C++ was harder, but then other stuff was easier. I left Ada when I was trying to do some research in generic programming and Ada refused to let me do things that C++ would because it was 'unsafe'. Sure, unfettered use of generics would be unsafe, but so is rewriting the same code 10 times for different types. This was back when Stepanov published his STL paper. His ideas were great, they helped me, and I didn't look back. Still, if I was to work on another flight computer or weapons system I would not look askance on Ada. The tasking model in particular is very nice.
I never understood the 'committee' argument. If you don't like something about a language, say what you don't like, don't talk about how it was created. Ada is very well designed, it is consistent, and it hangs together far more than most languages out there.
No, no one is going to use Ada to 'move fast and break things' (defeat Facebook). It's a language for measured development of things that you can't afford to have break. Not spending weeks chasing pointer bugs, and going home to your family at the end of an 8 hour day is pretty darn exciting to some of us.
I linked to a book in my comment that refutes what you say by showing how the constructs themselves avoid many problems. Further, there were empirical studies done by the military and defense contractors in the past that compared defect rates of Ada vs many other languages. Ada always came out on top, sometimes with half the defect rate. So, your claim is wrong in theory and practice.
The big problem in the early days was getting a compiler. DoD had a test suite for the compiler, and only compilers that passed could use the Ada name. They also had a "floor equals ceiling" rule - no missing features, no extra features. Compilers were to be feature-compatible.
That's how aerospace does things. The interface spec defines the interface. If something is incompatible with the interface, it's defective. It's why you can take Pratt and Whitney engines off a 767 and put on GE or Rolls Royce engines. DoD took the position that a compiler was a part with a specification.
Ada was a big language back then, and some of the compiler companies underestimated the job. Ada compilers were quite expensive - one for the M68000 was $40,000. I ordered that one when I was with a big aerospace company. When it showed up as a magnetic tape, it came with an unexpected cover letter, saying that this wasn't a validated compiler, and the validated compiler would follow - someday. No go. Quality control reject. Red tag attached: "REJECTED BY INCOMING INSPECTION - DOES NOT CORRESPOND TO SPECIFICATION". Purchase order says "validated compiler". Tape returned to vendor. Vendor tries to get out of giving refund. Legal department hammers vendor until they pay up. Meanwhile, another vendor ships a validated compiler, and that is ordered and used. That's how aerospace used to do things.
The compiler price was a big problem for non-Government customers. That contributed to the lack of adoption. We had great hopes for Ada, having used Modula successfully. But it was not to be.