Break Points
Ada Take Two
Jack Ganssle
2/9/2009 12:28 AM EST
Here's an email from someone who wishes to remain anonymous:
"I found your article on ADA very interesting as we had a similar dilemma in one of my previous employers.
"It was back in '99 in Cambridge, UK and the main founder/inventor/CTO of the company was engaged in both software and chip development. He got very involved with the chip development ,which was designed in VHDL, and he was so impressed with the language that he wanted the same level of robustness in software too.
"With ADA being similar to VHDL, he decided to switch software development from C to ADA, in order to raise productivity and produce code with less bugs. However, that didn't prove successful, and that had nothing to do with the effectiveness of the ADA language. Developers in the company started to protest, they said they didn't have the time to learn another language, they didn't contribute anything to ADA cvs tree and they almost refused to write anything in ADA.
"The arguments were so fierce that the CEO had to intervene, by firing the CTO and reverting development back to C/C++ and this effort came to an end.
"As, a chip designer, I find ADA more natural than C, but its mainstream adoption, is more down to "politics" rather than the technical differences in the language."
My initial reaction to this email was: Are the lunatics running the asylum? Who is in charge?
Embedded engineering is a wonderful career and a ton of fun. But the stark fact is that we're paid to achieve a business objective. That's it. The fun, creativity, the learning and all the rest that occupies our days is irrelevant to the business's need for us to produce and support products that generate profits.
The engineers' reaction described by the writer are typical of an outfit at CMM level -3. (Also known as "sabotage.")
But maybe things are a bit more nuanced. Matt Whiting sent this email to me:
"Unfortunately, even after having Tucker Taft present at [the company] and having many conversations with John McCormick and others, I could never convince my engineers to give [Ada] a serious try. I certainly could have mandated its use, but you know how successful that is (and the DOD also found out how successful the mandate approach was!).
"I still occasionally ponder the reasons why Ada never caught on. You mentioned a few such as requiring much more of the programmer upfront rather than during debug. I've become convinced that most programmers today actually like to debug! Thus moving effort from debug to design and coding isn't a big draw.
"However, in my humble opinion, the even larger issue is one of job opportunities. Many of my software engineers were concerned that becoming expert in a niche language such as Ada and losing their skills in C/C++ would make them much less attractive to other employers. I believe there is much merit in this argument and when I had to lay off 90% of my department, I thought about this issue.
"The issue of designing and developing error-free software is certainly very complex and involves more than just a capable language such as Ada, but with respect to Ada adoption, I believe that the DOD mandate actually hurt the language, limited its adoption, kept it a niche solution and that status now is a significant reason why individuals do not choose to use it. I suspect that had the DOD not mandated its use (after all, how good can something be if you have to be forced to use it?), it would have had a better chance to be adopted on its merits alone."
For very good reasons we jealously guard our careers. Getting pushed aside into maintenance, for instance, is a sure way to start one scanning the help-wanted ads (such as they are today). Though I'd think having Ada experience would round out a resume, there's no questioning the fact that C/C++ is the mainstream and the best route to getting a new job.
There seems to be a sort of career inertia at work. While embedded hardware technologies have the lifespan of a fruit fly, software technologies change at a glacial pace. C is 40 years old. It has dominated the embedded landscape for a quarter century. Despite decades of C++ availability, its use as an OO language amounts to less than a quarter of the market.
What do you think? Is software paralyzed by career inertia? What's your take on Ada? Leave your comments here at the end of this column and/or go to the Embedded.com Home Page and participate in the poll on this question.
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. Contact him at jack@ganssle.com. His website is www.ganssle.com.
|
|
|
|
|
NSC
2/10/2009 8:08 AM EST
I'd like to throw my two pence/cents worth in:
a) Working on some of the early real world Ada projects back in 1988, tasking *was* part of Ada84 but the actual implementation was, generally, awful. You were limited to the rendezvous, which caused excessive context switches. You had compiler vendors trying to implement real-time kernels without any real background in this area. The run-time efficiency was really bad, and at the time the memory requirements were pretty horrendous. Even with add-ons like ARTX (VRTX's Ada sister) it was still a kludge.
b) Many of the early, and very expensive, compilers were written to pass the Ada validation suite, and had no focus on performance or efficiency. We were forced to use "official" Ada compilers because they had passed the suite.
c) By the time Ada95 had addressed many of the issues the damage had been done to it's reputation (the FUD factor). And with Java appearing and many Universities jumping ship to teach Java it lost it's momentum.
d) Job prospects - already been said - but unless you're happy to be the modern COBOL programmer it's a brave person to take on Ada today as a new language. Also C still forms the basic syntax for so many languages
e) I'm not going to argue the merits of one language over another - you need a context; and while we accept poor quality/aren't prepared to pay for high quality then fad and fashion will always win out (hey pass me that F# book).
I'll stop ranting now...
Sign in to Reply
Paul L at QNX
2/10/2009 11:38 AM EST
Do some developers resist Ada because it is harder to use for prototyping? As you mentioned in your earlier article, "[Ada] makes one work very hard to get a compileable source file." Not what you want when you need to cobble together a quick proof of concept. I know next to nothing about Ada, so if this is a dumb comment, my apologies!
Sign in to Reply
DwayneU
2/12/2009 12:25 AM EST
Having talked with other dinosaurs that were around in the 80s 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 didnt 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.
Sign in to Reply
RMiller
2/12/2009 8:02 AM EST
Over the course of my 33 career, I've seen one thing in common for both hardware and software engineering in the U.S. - the people that get rewarded the most are the "firefighters" that swoop onto a project and with near-superhuman effort, resolve the issues and get the product out the door. Our society is addicted to heroism, either real or contrived, and moving to a language/environment/tool that could possibly preclude the opportunities for this heroism will never make sense to most of the individuals that do the actual work.
Think about it, who gets the bigger rewards and recognition - the person who never creates bugs in the first place, or the person who pulls an all-nighter and saves the day? Why would any person want to do away with their opportunity to get ahead? It may be an elegant thing to do, it may be in the best interests of the company, but it's not in the best interests of the individuals and their careers.
I've seen this at every single company for which I've worked, and I've seen it applied to all types of engineering efforts. I don't think it will change until upper management changes its mindset about what constitutes good engineering and who will get rewarded for their steady, predictable, non-adrenaline-pumping efforts.
Sign in to Reply
AndyBuck
2/12/2009 8:22 AM EST
A few observations in no particular order:
Most decisions on the use of Ada seem not to be based on any technical argument. This is a sad reflection on the state of our industry.
Current Ada toolsets & implementations are as good as anything else and often cheaper overall.
Lumping C and C++ together in discussions is severely misleading. They are very different beasts.
For a start C is 40 years old, C++ only 20.
C runtimes and compilers do not have to be particularly clever - that is left to the programmer. C++ runtimes have a lot of work to do.They do not always make a good job of it. An unskilled programmer can easily make a complete hash of using C++ "features", leading to poor peformance, excessive memory usage, bugs and hard to maintain code.
C++ implementations were as bad as Ada ones in the early days; this is still true. The only difference is that they are both considerably improved.
Lack of training/skills is a bad reason to reject Ada - have you tried to find a good C (not C++) course recently?
Lack of career prospects is a bad reason to reject Ada - have you seen many good C (not C++) jobs advertised recently?
It is no harder to knock up a quick prototype in Ada than in any other language. Often it can be easier than C or C++.
You can write poor and bug ridden software in Ada. Perhaps the reason that this does not often happen is that the people who use Ada are more interested in doing a good job than those who don't.
You can write extremely efficient Ada. In the 80's I used an excellent RTOS written in pure Ada - no dodgy tricks, no assembler etc. It was as fast as anything else then available in any language. It was also portable and easy to maintain...
Sign in to Reply
queisser
2/12/2009 11:48 AM EST
A lot of the comments here suggest that engineers are rowdy, inflexible and sullen bunch that will resist a good thing in order to stay in their comfort zone.
Generally speaking, this is just not true. As engineers we're paid to take technical and economic as well as many other factors into account.
If a truly better tool comes along we will adopt it, maybe not everybody, but on average it will be a success. If the new tool succeeds in one aspect but fails in many others it is simply not a success and if a small minority finds fault with a large, highly educated and rational group of customers it's not hard to see where the problem truly lies.
I don't know enough about Ada to make a strong claim here but I suspect that "unsafe" languages such as C/C++ and in recent years even "unsafer" languages such as Python are becoming popular is that there is a movement to use tools and processes outside of the language, e.g. test-driven design and automated unit testing, to verify that the software works.
Sign in to Reply
igrbt
2/12/2009 2:05 PM EST
Hello everyone.
The fact that C existing for 40 years and still in use is just amazing.
IMHO this is why:
C is applicable to be used virtually in any programming domain. What is is in it just sufficient. It is a language and a tool at the same time. C++ is OOP extension which
lets us to exploit OOP methodology as necessary. Now are there many limitations that prevent us to use C/C++? - Not at all
Speaking of Java and Ada which have in common synchronization support (e.g. thread safe) they don't possess a crucial advantage over C like language at least, not sufficient enough to take over C/C++ popularity.
Sign in to Reply
Scottish Martin
2/13/2009 7:19 AM EST
Jack, in response to the email from Cambridge, UK, you posed the questions "Are the lunatics running the asylum? Who is in charge?"
I worked in an organisation in the UK where we deployed large, complex, safety-related software systems. My immediate supervisor was a Mathematician, who's software knowledge could be summed up in one word, "None" - his wife had provided him with a few buzz-words to get past the interview. My supervisor's manager was a very posh Chemist - clueless. Next up the management line was a Mechanical Engineer - political animal. But the chief lunatic in our asylum was the CTO, he was a career DIPLOMAT - I am sure he believed that networking was about honing small-talk skills at cocktail parties, and that Ada was the finance director's mistress.
What is that saying about fact being stranger than fiction?
Sign in to Reply
GregK
2/22/2009 5:14 PM EST
1. Do someone recommend any good book to learn ADA?
2. I am googling and really can not find to many ADA compilers. I found Green Hills what have ADA compilers for 32bits cpus. I have found some gnu tools for ARM. that's all what I found.
What about 16bit microcontrollers?
Is nowadays ADA destine for smaller platform and if alternative in price field? I can not find any particular price for ADA compiler.
Sign in to Reply
Scottish Martin
2/23/2009 5:35 AM EST
Follow link:
http://www.adacore.com/home/
Sign in to Reply
Michael_F
2/23/2009 5:42 AM EST
Or link:
http://libre.adacore.com for Free Software development.
The GNAT technology has been ported from 8-bit (Atmel AVR microcontroller) to 64-bit architectures.
Sign in to Reply