Why don't you program in Ada?
Eighty-five percent of us create embedded products in C or C++. Java accounts for another 5%, Forth about 3%. Ada scored a pitiful 2%, coming in even behind “other,” according to nearly 1,400 respondents to an Embedded.com language survey.
I like C, mostly because it's rather like assembly language. Both give me total control of the machine. Assembly is particularly fun due to its cryptic syntax and the ease — or even the necessity — of creating tricky and clever constructs. But these are lousy reasons to select a language. Worse, they suggest that both C and assembly are not appropriate for building big, complex systems that must be reliable.
I think Ada is the only language designed to significantly reduce and maybe even eliminate dumb programming errors. What a novel concept! Ada's rigorous syntax traps most silly mistakes during compilation. C, by comparison, lets practically anything through, so we spend far too much time debugging. I've observed that most embedded developers spend about half their programming time debugging. Spending that much time debugging is ridiculous, and it's clearly the first place to focus when looking for ways to speed products out the door.
A strict language with draconian syntax rules can cut debug times dramatically. The old rule of thumb with Ada is “if you can make the damn thing compile, it'll run correctly.”
Most of us have been driven mad chasing elusive bugs only to find the compiler did something quirky, or even totally wrong. That's unheard of in the Ada world, since the compilers are essentially perfect. Each must undergo an exhaustive validation process before being allowed to use the Ada moniker by the trademark holder. By comparison, a C compiler might not even be ANSI-compliant. One I use here doesn't even support linking.
Yet for some reason it has almost zero market share in the embedded space. Why?
Could it be that we developers are intellectually lazy, and want the immediate gratification of compile and test? Most of us hate satisfying the demands of a tool. That's probably one reason so few folks use Lint, a very powerful aid to creating syntactically-correct C. But Lint is, as it must be, very picky and thus frustrating.
Another Embedded.com poll showed that 70% of us chose our development language based on business issues rather than technical suitability. One very valid business reason for Ada's failure is the lack of tools. The lively compiler/debugger market so typical of C and C++ never came about for Ada.
Or were we afraid of the memory needs of such a big language? It was never meant for 8051 or other resource-limited applications. Yet the same can be said of C++, which is healthy and has a growing user base.
The Defense Department was the language's primary advocate, swearing that contractors would have to adopt it for all major programs. DOD caved, first allowing a few exceptions, then many, till now Ada is more an interesting historical aside than part of every developer's zeitgeist. Is the government at fault for not being strong despite the vigorous opposition that always surfaces when anything new comes about?
What do you think?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at . His website is .
I downloaded the “gnat” freeware version of Ada, and lo and behold! the first program shown in the user's guide was “Hello, world!”. IT was easy to enter, compile, run. Then I looked at the size of the executable. This may be a VERY good reason Ada has not taken off — 215,746 bytes! To print “Hello, World!”!I ran comparisons in Quick BASIC, Turbo BASIC, Turbo C (v.2.0), and Turbo PASCAL (v.5.5). I got:
QB: 3,280 bytes (+70,680 for brun)
TB: 29,024 bytes
TC: 8,358 bytes
TP: 1,840 bytes
I do not know if there are switches to make the Ada file smaller, but, my goodness!
JACK REPLIES: Have you tried a hello world program in C++? Yikes!
With respect to “Rich Ries” message:
“I downloaded the “gnat”freeware version of Ada…”It is a shame he didn't read further into the GNAT documentation or he would have realised he had linked in the entire runtime kernel(effectively the Ada “OS”) as well.The actual size of the object file is (on my WinNT PC):2,191 bytes
Lead Software Engineer
Avionic Systems, BAE SYSTEMS
I attended the US Military Academy at West Point class of 2000. The entire curriculum was in Ada95. Ada was my first exposure to OOP and I constantly compare the shortcommings of C/C++ to Ada. Now as an embedded systems designer in the electronics industry, I work mainly in C and assembly due to lack of Ada tools that support my chosen MCU.
My point here is, you go with what you know unless forced to change. The problem here is the human factor: we take the path of least resistance and fear the unknowns when dealing with problems. A good friend of mine, an electrical engineer, said it best. “Out of the thousands or so components an electrical engineer can consider for a given design they go with the 10 or so parts that are sitting on their bench–the ones that they have experience with.”
I would love to see Ada become a language of choice in the coming years. The truth is, software developers cut their teeth on C/C++, they go to work at companies that use C/C++ and when they get in the manager's chair they mandate C/C++ because their experience is based in those languages.
Embedded Systems Designer
JACK REPLIES: My theory of language use is that new languages won't be adopted till the old farts die. We do what we're familiar with, which is one reason it took 20 years for C to become the normal language in embedded work (20 yrs=1 generation), and one of the many reasons C++ is still a small part of ES work.
Thanks for the interesting article, I like to see Ada get some exposure.My experiece has been that most people don't use Ada for a number ofreasons.
#1 They've never heard of it. (Again, thanks for the article)
#2 Their tool vendor gives them a C compiler, so why pay for somethingelse?
#3 Nobody uses it. (Self fulfilling prophecy)
When our company was forced to move our software base away from VAXhardware (obsolete), to PC's (cheap and powerful), I managed to persuade thegroup to use Ada. There have been no regrets.
Early in our migration we did some work in C++, some in Delphi, but mostin Ada. A few programmers started using C++ on the PC, then shifted to Ada.They don't want to go back.
Assuming for a minute that your article on Ada's slide is not just troll-bait….
Your poll is probably meaningless since it is possible that a large percentage of Ada programmers do not visit embedded.com or care to answer yet another “my favorite language” poll.
Your praise for Ada is probably an overstatement of it's abilities as is your implication that tools were not available for Ada. They were, and they still are, but now many developers are focusing on Open Source Ada (GNAT). There are still quite a few engineers using Ada in the aerospace industry. It is probably premature to say it is going into oblivion.
I see Ada falling into disfavor because Ada tool vendors have/had pricing structures set up for tier-one DOD vendors with *very* deep pockets.
That doesn't fit the budget of the more typical embedded design house. And as DOD contracts have gotten more competitive and the smaller, more nimble companies have gotten involved, they've refused to pay exhorbitant prices for tools. Hence the exceptions.
Nice, thoughtful editorial.
Admitting up-front that I've been an Ada advocate for 20 years now, and that most of my involvement has been in real-time or embedded applications, I'll say the following.
The language is hardly as draconian as the myths make it out to be – the compiler is your friend.
While successful compilation gets you a lot of the way there, and is particularly helpful in catching inconsistencies when changes are made, it's not a guarantee that the application will work correctly. But it does go a long way towards it, and I generally find myself spending little time in the debugger.
Because the code is very readable when written with a small amount of care, it's easy to come back to something several years after writing it, and quickly come back up to speed.
Because Ada's concurrency facilities abstract common concepts found in many threads libraries, porting is relatively painless. No special adaptations to the RTOS facilities are necessary when Ada is implemented over one, and code for “bare” Ada implementations is equally adaptable.
Finally, there are good tools. My company is the maintainer of the open source GNU Ada compiler (GNAT).
There are public versions available free on a number of platforms (ftp.cs.nyu.edu), and many other open source packages available (www.adapower.comor libre.act-europe.fr). There are many more ports available under licensing for a variety of RTOS.
It's been discouraging as an advocate of a fine language to see companies migrate some projects to other languages due to lack of popularity (ie can we find programmers)?
For those who've only heard the myths about the language, perhaps taking advantage of one of the free ports to actually try it out could be an illuminating experience: it's a very fine language for any kind of systems work and supports OO very nicely as well. The portability savings alone are worth the price of admission.
Ada is a language that got a bad rep because it was ahead of the curve, trying to address problems 10-15 years in advance of the general industry. Both its original '83 version and its '95 revision are very clean and consistent designs that work the way you expect them to once you've acquired their basic concepts.
These are good things.
Ada Core Technologies
I'm not sure that “DOD caved, first allowing a few exceptions, then many, till now Ada is more an interesting historical aside than part of every developer's zeitgeist.” is quite correct. As I understand it, they still consider the language on a project by project basis. I hardly expect that the requirement has gone away for critical systems, like weapons and flight systems.
I myself discovered Ada95 a couple of years ago, after being a hardcore C/C++ guy. Now, all my open source development is done in Ada95 using GNAT. I spent too much time debugging in past projects. With Ada source code, debugging is a small part of my development time and I like things that way!
I think perhaps that the high cost of Ada compilers has been a traditional impediment to a more general acceptance of the language. It might be too late now, but there is just a chance that free compilers like GNAT may bring about a renaissance in that art. Certainly there has been a significant increase in Open Source-ed development in Ada since GNAT has been made available. Universities are using it more as well. Only time will tell.
Even Microsoft is waking up to the fact that they need to improve software quality. If they go far enough down that road, they may even enlighten themselves into using something other than C/C++! Again, only time will tell.
I just read your last article in Embedded.com and I was very interested. I was also a bit surprised by what you called the old rule of thumb : “if you can make the damn thing compile, it'll run correctly.”
I have been working for more than 16 months now on two defense projects (ADA on Linux, and now on HP-UX) and not only do we perform tests on all the code we develop (component wise and integration wise), but we also perform peer code review.
Just last week, part of my code was screened. It compiled fine but my peers found a couple of faults. It would not have run correctly.
Personally, I enjoy coding in C and specially in C++. However, since ADA is more strict than C and C++, it forces developers to code in a more rigorous way and thus allows us to produce software that is more reliable and less expensive.
As a lecturer of Ada in universities for many years I have found that a lot of academics are openly dismissive of things they know nothing about, and that this flows onto students. Intellectual curiosity seems to take a back seat to picking up on 2nd hand criticisms (in many cases unwarrented). Unfortunate.