Re: NOACE- End of the road for Ada?

[Marin David Condic <nobody@noplace.com>]

adaworks@sbcglobal.net wrote:
> 
> "The horror!  The horror!"
> 
> Richard Riehle
> 
> 

I appreciate the reference to one of my favorite movies. :-)

Your comments are well thought out (as usual) and I generally agree that 
we do see a lot of bad reasons in DoD contracts for the choices of 
languages. I'd depart slightly in this regard: The guys making those 
decisions usually are much more concerned for the overall success of a 
weapons system program to worry too much about what flavor of nuts and 
bolts are selected to go into constructing various parts involved. 
They're concerned above all with making sure the whole project comes in 
on budget, within schedule and that it passes acceptance tests meeting 
overall objectives. Programming language choices are so far down below 
the noise floor that they just trust the guys doing the job (and hold 
them accountable) for getting it done. Perhaps it ends up taking longer 
and costing more to get it right, but so long as the guys doing the job 
guessed right in making up the schedule, it never really surfaces.

That said, I'd also suggest that its about time we just quit counting on 
the DoD & its contractors for the welfare of Ada. Its a huge 
disappointment that they've chosen to ignore & marginalize their own 
language, but that's what they've done and there isn't much we can do 
about that. They simply don't see the language as having a significant 
following in the "Real World" and they stack up the pluses & minuses and 
come to the conclusion they'd be better off going with what seems to be 
dominant technology in the rest of the industry.

So if we quit relying on them to sustain Ada and go out there into the 
"Real World" and find ways of employing it in potentially new & growing 
technological developments, perhaps one day Ada becomes the dominant 
language in some field. Why don't all the Ada guys who build embedded 
systems think of some new device they might construct & market and use 
Ada as the technology going in to make the zeros and ones? Why don't all 
the Ada guys who build network applications think of some new and cool 
networking capability and go start developing the underlying 
implementation in Ada? Why don't the Ada guys who build financial 
applications think of a better way to address someone's accounting, 
payroll, inventory, etc. needs and build some marketable application in Ada?

Enough of the tools exist already and with sufficient quality and at 
affordable prices that there is not much to hinder using Ada to 
construct some end-product. The guy who buys an automotive diagnostic 
computer doesn't care what language you programmed it in. The guy buying 
  some wireless network remote control home appliance doohickie doesn't 
care if you programmed it in Ada. The guy streamlining his business with 
your automatic inventory management & ordering application doesn't care 
what language you programmed it in. If we build end products like this 
that have some commercial success, people who want to program in Ada 
will find jobs and compiler vendors will have customers to keep them in 
business.

The point being that if we quit worrying about the DoD and quit thinking 
strictly in terms of software development tools (although it is 
important to have them) and START thinking in terms of "How could I 
deploy this technology in building a BETTER end product in my field of 
expertise that might have a marketable future?" we might see Ada find 
some productive niches and we might see more Ada jobs created. Perhaps 
eventually the DoD would come back and rediscover their own language.

MDC


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "'Shut up,' he explained."

         --  Ring Lardner
======================================================================