Why aren't developers interested in Ada?

1/27/2009 5:55 AM EST

Ada is a fine "professional engineers" language, but there are a number distinct disadvantages that have combined to restrict Ada's acceptance in industry:

(1) Too much emphasis is placed on programming languages generally - expensive errors are requirements and design related, not implementation based. Read the Ariane 5 accident report if in doubt!
(2) Market forces dictate language and tool popularity. The DoD recognised this and withdrew support for Ada in late 1990's.
(3) Ada compilers and suport tools were too expensive in the 1980's and 1990's - some of these were also poor quality.
(4) Non-professionals (i.e. Pseudo Softies) prefer to be unconstrained by all engineering discipline - that includes programming.
(5) Ada's adoption of true Object Orientation lagged behind other languages - this restricted its popularity in non-embedded applications.

A professional team can develop quality software whatever the chosen implementation language and toolset.

1/27/2009 4:23 PM EST

Count me among Ada's supporters, even though it has been almost 10 years since I last used it. My experience was much as Jack describes: resistance at first, then enthusiasm after success working on two big embedded Ada projects (in the defense industry, of course).

Martin makes important points about what has hurt Ada, not the least of which is #3. IIRC, the first Ada tool suite I used in the early 90's cost 20-40K per workstation, and we furtively wished that Borland or Microsoft would come out with Turbo or Visual Ada. That feeds into #2, because a common complaint I used to hear was the lack of Ada programmers. A bit of a chicken-and-egg problem, I think. And once Ada 95 gave us true OO, as pointed out in #5, you couldn't help but feel that Ada 83 was really only going to get one shot at C++, and blew it.

IMHO, the DoD Ada mandate caused a reaction against change, as contractors had been used to the freedom to pick the language for their projects. DoD *had* done so before with COBOL, but in the end the PC revolution meant that they were not the 600-pound gorilla anymore and couldn't keep everyone from using C/C++.

Still, there's a lot of things in Ada that I hope other languages will pick up, and in the meantime I've gotten the same enthusiasm for Python....

1/29/2009 1:50 AM EST

Quite honestly, I didn't know Ada was still around as a viable production language for new projects. Right now, I work mostly with 8-bit microcontrollers and CPUs, so I generally use (PIC / Freescale / Z80) assembly and some C. There seems to be a much larger codebase for both of these (particularly C), as well as a much larger pool of instructional resources (books, online tutorials, examples searchable via Google Code, open-source projects, etc). For me, this would seem to trump what Ada has to offer. I also think that, if interviewing for an embedded design position in the future, it will be in my best interest to learn the languages in use by most organizations. C is probably not the absolute best language for embedded design -- but it represents a very good compromise for a lot of diverse applications, and there's a lot to be said for that.

--Eric
Computer Engineering Technologist
www.paleotechnologist.net

1/29/2009 8:44 AM EST

I agree with Jack, Ada is a very strong language that unfortunately suffered from bad decisions in the very early days, the primary one being EXPENSIVE compilers and tools.

I also agree that the DoD mandate probably didn't help it in the long run since too many people objected to the language simply because it was forced on them.

I've programmed in Ada, C, & C++ and give me Ada any day! Ada enforces the engineering principles that we should be following but the hacker mentality the dominates this field pushes back against that since they have a cheap & "easy" language like C to use instead.

If only GNAT had been around in the 80's for Ada...

-- Doug Lewis

1/29/2009 9:49 AM EST

The mandate for Ada in military electronics artificially inflated the cost. The mandate that Ada compilers be adherent and certified to a specification also pushed the cost.

We are still developing with GNAT Ada, though the market pressures force the inevitable: All code is being ported to C++ for the next generation of widget because there are few Ada developers available.

C and native assembler are always cost effective and available for the CPU/MCU/DSP products.

1/29/2009 12:02 PM EST

One important attribute for a programming language to be successful is that it is taught in schools, with early adoption by youngsters creating a waterfall effect. The fact is that many high schools have classes in C while Ada is rarely seen in colleges. I think that's a big factor. For wide adoption, a language needs the support of academia. I realize at this point in time, it's somewhat of a chicken-or-egg thing. So maybe one question would be: Why wasn't Ada adopted more widely by academia when it first arrived on the scene?

1/29/2009 12:41 PM EST

One of the things I really like about Ada is that it (along with Fortran and Matlab) knows what an array is and how to work with it.

When I was doing a lot of VMS Fortran, I estimate that array bounds checking caught about 30% of my mistakes.

A slogan I came up with a few years ago:

In C, an array is a pointer, an offset, and a prayer.

1/29/2009 1:55 PM EST

No language is perfect; variants, offshoots, and enhancements will continuously evolve, or else progress stagnates.

Ada, Modula-2, Eiffel, and occam have all offered good ideas for adding rigor and reliability to all the myriad descendants of humble old Algol.

It is a pity that C/C++ rocketed to such popularity that there exists a generation of language bigots, who worship C/C++ as a sacred cow; diversity is more important than ever, with multicore/distributed MIMD/AMP architectures emerging as the way to approach sophisticated problems -- to buck a prevalent myth, my own experience with partitioning tasks across multiple disparate CPUs has been that the job was simplified, easier to develop, and *much* more reliable than multitasking on an iso-architectural CPU (multicore, or not).

Matching (and possibly tailoring) the right tool to the right job is what's important; forcing a one-size-fits-all language with an arbitrary fiat (no matter how well-researched or well-intentioned) will always be doomed to ultimate failure, and do more harm than good -- much like the idiotic myth that assembler coding is un-necessary.

Now, why do I still often prefer FORTH for 99% of my work? Probably because of it's inherent mutability... :-)


vic plichota
MQR system architect
http://machinequiltingrobot.com/

1/30/2009 5:39 AM EST

We use Ada for a large desktop/PC application. I can certainly confirm that even outside the embedded domain, it's an excellent language for development. "Silly" bugs (pointer problems, addressing outside arrays, etc.) are almost unheard of here.

We have managed to produce an incredibly powerful application with a small number of developers. Something that in any other language we would not have been able to do.

I always remember, a senior developer saying to me: "I've got a bug in this code that the compiler hasn't found. Can you remember how to use the debugger, we use gdb don't we?"

Ian
Rapita Systems Ltd
http://www.rapitasystems.com/

1/30/2009 10:24 AM EST

We still teach Ada to our students at the University of Northern Iowa. From 2000 to 2007 we taught Java in CS1 and CS2 and Ada in CS3. The faculty unanimously agreed that our use of Java for beginners was a failure. Starting in the Fall of 2007 we began two parallel tracks for Freshman. One track taught C/C++ in CS1 and CS2, the other Ada. Students now get Java in CS3. The first groups took CS3 last Fall. The CS3 teacher reported that in the final grade distribution ALL of the students with the Ada background did better than those with the C/C++ background. Numbers are too small yet to publish an education article, but it is certainly looking strong for Ada as a good language for teaching beginners.

2/2/2009 11:45 AM EST

Having talked with other dinosaurs that were around in the 80’s era when Ada was initially mandated, I think that two factors were primary contributors to the limited acceptance of Ada.

First of all, the DoD mandate. This had two effects. First the US defense industry bristled at being told that they had no option other than to use Ada. Western thinking sometimes elevates the freedom of choice above an acceptable constraint. The second effect of the mandate was that immature compiler had to be used to make program schedules. Quickly release immature complier suites provided buggy development environments and less than efficient code generators. The initial impressions of a new strongly typed language, mandated use, buggy compilers and poor code generation are hard to overcome.

The second factor was the pricing approach of the compiler companies, which was also influenced by the DoD mandate. Ada compilers were obviously more expensive to develop. Many (mabe all?) compiler companies decided to increase the cost of licenses to pay off the development costs in a very short period of time (ie. a small number of seats). With the DoD mandate in place, this seemed like a viable financial approach to recoup their investment quickly just in case this Ada-thingy didn’t catch on.

With two decades or so of Ada history behind us, there are still language battles, but for the most part, I see the Ada market share decreasing.

2/4/2009 10:30 AM EST

As a VHDL developer (derived from ADA) and past ADA developer I admit I had to "learn" to love the languages, but the payback is HUGE. In ASIC land (where VHDL is used) the industry rule of thumb is that 70% of ASICs need a respin. We recently developed three large ASICs in parallel (all in VHDL) and all three of them were first pass successes. According to the industry averages two of them should have failed. We had to put a ton of effort into developing packages etc. before we could start the "real" work to developing the ASIC (i.e. application) but the payback in self-checking etc. is unbelievable. I contrast this with Verilog (used by the majority of ASIC developers and more C like) which has a lower barrier to entry, but I think the direct result is the high failure rate. I think people are so worried about getting something quick, with very little thought or effort, that they overlook the benefits of a more structured thoughtful approach to the problem. Bottom line, the language you use IS important.

2/4/2009 12:49 PM EST

From my POV, lack of investment by companies and somewhat by academia.
Training budgets are, or can be, lean. So companies rely on academia to get them ready-to-go engineers.
To get comfortable with Ada, you need some substantial trial programs under your belt, roughly a semesters worth, AFTER the book learning.
AdaCore is trying to jump start this (http://www.adacore.com/home/academia/members/) with tools, materials, and internship coordination.
But, they're working out of a hole that was dug (at least here in the United States).
In academia in my state of Texas, I'm disappointed that only 3 university campuses have it.
When I tried to use Ada in post-graduate work at a local University of Texas campus in the mid-90s, it was somewhat like pulling teeth.
"Begging" professors, sometimes getting turned down, and only one professor on staff who taught it in a non-offered course.
In companies, I've seen local job listings for converting Ada to C.
I'm bummed.

2/4/2009 1:23 PM EST

I'm one of those dinosaurs that was first exposed to Ada in the early 80's and fell in love with it. It was painful to be one of the few touting (and proving) Ada advantages only to be shouted down by others for many of the reasons stated by others. When it all came down to the end of the argument it seemed decisions were made on emotion rather than logic - "We can't have the government dictating how we develop programs!".

So now I fight my battles with the abomination that is C++ when I know that I could produce the same functionality better, faster and cheaper using Ada.

For those that say that Ada isn't a good choice because there aren't enough trained developers I would counter that someone can be trained to be a proficient Ada programmer far quicker than it takes to train that same person to produce acceptable code in C++. And you can rest assured that the code produced by that Ada developer is of better quality and higher reliability that the C++.

So... why aren't developers interested in Ada?

2/5/2009 11:40 AM EST

There's One More Thing: Ada also provides a substantial, well-defined, -portable- set of facilities for multi-core/concurrent software development. Ada83 language features and compilers were developed along with the multi-CPU machines in the '80s (e.g. Sequent, Encore, etc). Ada95 built extensively on that experience base, long before the current "crisis" in multi-core programming. The -same technologies- work just great for the new crop of shared memory multi-core chips. (See this article for how someone wrote a program to keep all of the cores of a big Sun multi-core machine, fully occupied, all written in standard Ada: http://www.grebyn.com/t1000/ -no business connection except that the developer is a friend of mine of long standing and gives me an account on his computer for personal email :-)

2/5/2009 12:04 PM EST

At university, for an undergrad real-time systems course we had to do a project in Ada. It was some sort of a factory automation simulation as I recall, to process widgets on an assembly line. Coming from a C background the verbosity and typing of the language was a bit overwhelming. Luckily one of the members of our team had experience working with Ada at Hughes for a flight control system, so he was able to bring us up to speed. The way tasks, variable precision, and typing is done with Ada was interesting. At that time Ada had poor object orientation abilities, and the language is clearly not originally developed for OOP. Personally, as a Java proponent, I'm surprised Java is not used more for embedded. Perhaps Google Android will change that... at least at the application layer.

2/5/2009 1:36 PM EST

I have to come down on the "Why not" side of this question.
I have programmed in machine code, assembly (MC68xx and i386), Pascal, PL, Lisp, C, C++ and various scripting languages including awk, shell (sh, csh, bash), perl and Tcl, as well as hardware design languages including VHDL and verilog.
I tried Ada (using a CD edition from ca. 1998) and disliked it. Here are my reasons (which hold for Pascal and PL which also are not very popular among programmers):
A. It is not case-sensitive, which limits the name space in a big program. Originally, case-insensitivity was to speed sorting on ancient mainframes; it is no longer important for system or application programming.
B. It is too wordy. Why should I have to keep typing "BEGIN" and "END" when C or C++ saves screen space and attention with '{' and '}'?
C. It is not consistent, as is not PL. Ada seems to be a "Do-All" language, a well-chosen collection of features, as opposed to a language carefully designed to be consistent with the OS and with itself. This may be contrasted with C and, to a lesser extent, C++.
D. It permits the irrational idea of declaring procedures within other procedures, like Pascal. This make such procedures nonportable and thus, to some extent, a waste of effort.

On a positive note, Ada has built-in support for concurrency of execution; but, for me, this isn't enough to bother with it.

2/10/2009 1:14 PM EST

She came to the party to dance
With a pert and disciplinary stance
But for her partner to be
She chose D.O.D.
From then on there was never a chance

That and the arrival of BDS C on the scene.

2/12/2009 2:24 AM EST

Although C wins the popularity contest as the language most typically chosen for real-time embedded systems, other languages are worth considering. One of them, Ada, offers advantages over the C family, especially in high-reliability environments. Another, Java (as extended with real-time enhancements), may be especially attractive in highly dynamic systems.

View the PDF document for more information.
http://www.eetindia.co.in/ARTICLES/2003DEC/EEIOL_2003DEC02_EMS_TA.pdf?SOURCES=DOWNLOAD



For more Technical papers and application notes on embedded & system design including controls, embedded OS and firmware.
Please view our site: http://www.embeddeddesignindia.co.in/

2/13/2009 1:57 PM EST

Not too many years ago I was part of a team that coded missile acquisition software, in other words we made embedded circuits that were used in one type of missile to shoot down another. All of our work was done in Ada precisely because it was far more reliable and far less complex to create applications that could 'think' in real time.

Creating multi-tasking, real time code is pretty much where Ada excels in my book.

2/20/2009 4:36 PM EST

I am a developer though my area of expertise has nothing to do with embedded systems, actually I develop and design on SAP (ERP) implementations.
Anyways, as a developer myself I remember how back in the 90's, while at university and still learning about and how to do good programming, I found Pascal a real pain while C fascinated me from the very beginning. But with the gained experience, part in C but mostly in ABAP, I've realised how easy can anyone write crappy programs that will fail after the third day in use by cruel users (and SAP applications are in general less critical than avionics, medical and other embedded software).
So now I'm learning ADA on my own thanks to GNAT and I enjoy all the potential and strong typed features it has. If everyone abbandons ADA to do C/C++ who knows, I'll eventually find myself abbandoning SAP to do ADA.

2/20/2009 9:40 PM EST

The Boeing 777 flies 99.9% on Ada. isn't it enough say? Ada has been used in very large and highly safety critical applications development such as Boeing 777, defense and medical fields. We don't find Ada in most consumer electronics such as cell phones because Ada runtime requires more memory and computing power.

We don't see traces of Ada in iPhone and iPod Touch because the SDK and GUI are in Objective-C. We don't find Ada port for iPhone and iPod Touch because few Ada developers are interested in developing applications for them (or may be there are some but the number is not large enough to justify the effort).

There are limited teachers in schools with Ada knowledge and experience. Some of them have retired.

Students, nowadays, do not want to explore new language themselves. They are dependent in learning new things. The reason is very simple: They will not earn credits for their course. So why bother to learn.

This leaves to only a few people who have the desire to dig in to explore and discover the beauty and the power of Ada.

If you are in some social networking sites for professionals, you will not be surprised to see messages posted to Ada group searching for Ada developer with the requirement of "Top Secret" clearance. Do you see such job postings in C/C++ groups?

4/8/2009 9:37 AM EDT

Jack Ganssle has made the point that Ada provides run-time
checks that ensure that programs don't divide by zero.

But wait, there's more!

In any programming language it is easy for the programmer to
explicitly check for division by zero, and most coding standards
recommend that this is done. So I've even seen code like:
if Speed_of_sound /= 0.0 then
Time := Distance / Speed_of_sound;
end if;
despite the fact that the speed of sound is never zero.

The trouble is that these coding standards (and programmers)
are assuming that divide-by-zero is the only cause of overflow.
It isn't! For integers, dividing by -1 can also cause overflow.

For real numbers, dividing by anything between -1.0 & +1.0 can
cause overflow (and zero is only a special case of this), and
often does. Also any multiplication, addition or subtraction,
(of real numbers or of integers), can overflow.

These overflows do not necessarily represent coding errors.
The requirement may be to detect and report the problem, or
to continue with a limiting value. But in most of these cases
there is no easy way to check the operands beforehand to see
if the operation will cause overflow.

This is where Ada really scores, because, rather than either
ignoring the overflows completely or bringing the system
to a grinding halt, Ada detects all of these overflows,
and permits the programmer to insert exception handlers,
at an appropriate level, which take appropriate action.

5/7/2009 9:22 AM EDT

I'd have to disagree with JMWilliams with regards to nested procedures as being a waste of time.

Nested procedures do not necessarily have to be unportable. It's all a matter of the quality of design behind the implementation. I've found them to provide some rather elegant solutions to add structure in otherwise complex procedures (where decomposing the logic in them into smaller, external procedures end up being uglier than expected.)

When used judiciously they do provide an elegant solution. For that matter, even a GOTO can provide an elegant solution. No type of statement or language is without implementation risks. Nested functions, co-routines, anonymous/inner classes, closures, multiple inheritance, mixins, pointers to functions, GOTO statements and what not, they can all provide an efficient, if not elegant solution to specific problems... or they can make maintenance and debugging a nightmare. It all boils down to the programmer.

I hope I hadn't derailed the topic of discussion into the realm of programming languages in general, but I don't think nested procedures in general, or in Ada in particular, are a bad language feature.