In the goverment contracting world in the 90s ADA was very common. The DoD mandated ADA in some development contracts. So, I can see how someone from this world might make the mistake of calling ADA mainstream.

In this domain a clear view of the hardware is important for maintenance. The hardware/software interface is where a lot of troubles may be found. Finding a problem with this interface through a VM takes longer to troubleshoot.

Back to language selection in this industrial segment. There were contract requirements imposing a particular language. Also upper managment might impose a language choice. Allowing the actual software engineers to select the programming language is a recent and not yet widespread change. How I read the sentence about selecting a language is to say the engineers doing the works should do so since they know best what the needs are.

I don't get the hate on Ada. It has built in tasks/threading, strong typing, low level access when you need it, generics, native compilation, a decent toolchain, an open standard, ...

[1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

It's Pascal like syntax. In the 80's there was a very real Pascal vs. C war, literally based upon "BEGIN" and "END" being too verbose compared to "{" and "}" argued by guys with 300bps modems and crap like that. Pascal got an unfair bad rap. Ada looks an awful lot like it though.

Then C, especially old school C can almost be converted into assembly by YACC without a real compiler. While it's very hard to make a good or great C compiler, it's not hard to just make a C compiler. Ada came with a much larger library and then, if I'm not mistaken, there was a certification process to make sure your Ada was really "Ada" and that was fairly pricey.

It's worth a look if you're doing some kinds of green field development, the GNU Ada compiler is pretty good. I think there was a plan for like an eclipse plugin too.

Ada suffered for years for being an unimplementable language. It was a long time before compiler technology caught up with it, but Ada found it hard to shake that stigma.

C came along at the right time, did not have those problems, and so took off. On the PC, for example, in the early days C was the only possibility other than assembler.

Could you explain what features of the language made it that hard to implement?

I would really like to see your general opinion on Ada from a language designer standpoint. Considering you're the main mind behind D - did you draw any inspiration from Ada while fleshing out the language?

I don't recall just what it was that made it hard, other than being so complicated. I doubt I'd feel the same way looking at it now, as I have a lot of practice implementing complex features from writing a C++ compiler :-)

What I find attractive about Ada is the emphasis on writing programs that are checkably correct. I believe that, with the ever increasing complexity of software, better and much more mechanically checkable encapsulation, etc., is the way of the future, as opposed to what I call "faith based programming" where you overly rely on the programmer not making mistakes.

A large focus of D has been and continues to be on being able to write mechanically checkable code.

Kernighan himself weighs in: http://www.lysator.liu.se/c/bwk-on-pascal.html

Then C, especially old school C can almost be converted into assembly by YACC without a real compiler

I'd be interested to see this, if you have an example - for example how does it manage the stack?

Ada is a fairly strict language that allows for compilers to do a tremendous amount of static checks.

Do you realize that this report is written in "electronic design", or an embedded systems journal? It's not talking about the PC desktop here.

I don't know the exact numbers but Ada still plays a big role in security critical systems (airplanes etc.).

> Managed languages lead to "applications that are difficult to maintain over time"?

I think this is true regarding to embedded systems because they evolve very fast. Microsoft would have to take much effort to be on par, for many different kinds of embedded systems. The second point is that Microsoft's support for their operating systems is not unlimited. So if you have a long lasting embedded system technology then you simply cannot afford to use .NET.

I quit embedded in about 2005. I dealt with avionics and guidance systems. They don't evolve fast. When I quit, people were still using RCA1802 cores and ASM for some tasks.

.net on windows CE is still out there in force and is well supported. There are literally millions of devices out there with 20 year support contracts on them.

Is there a renascence of C++ and ada in those domains? That is to say did they ever leave. I don't remember hearing about a big push to have embedded software for airplane controls written in C#.

It's a shame, because there really is something to the C++ renaissance (I wouldn't know about Ada), and the shortcomings of Java and other managed languages in a few fields. It would have made an interesting article.

As a very long term C++ user, I find it much easier these days to write safe, efficient and maintainable code than it used to be. Much of this is due to the wealth of documented good practice and my own personal experience, but also due to language improvements, especially in C++11. C++11 is how all language updates should be: reduced verbosity, increased safety, common practice made standard, and even improved efficiency.

This is kind of like saying "Writing in FORTRAN is several orders of magnitude less efficient than letting developers use assembly" yes, a smart enough engineer can write assembly that is, at worst, no slower than FORTRAN (proof by fact that FORTRAN compiles to assembly). But this doesn't mean that on real-world projects FORTRAN won't win.

Pointers are, by default verboten. Pointer arithmetic will generate a compiler warning.

People should genuinely look into this stuff more rather than just dismissing it offhand. Ada got almost everything right for a procedural-OOP language. It was just too far ahead of its time.

And Java is often 1-2 orders of magnitude less efficient at memory usage than C++, so while 'several' is perhaps hyperbolic the general point still stands (execution speed wasn't being discussed).