Re: Ada Compilers

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

"John R. Strohm" <strohm@airmail.net> wrote in message
news:2AEB9D17A335FB6F.78506B6494B0AFF3.EE290620571FE224@lp.airnews.net...
> I'd be VERY interested in seeing a fairly detailed example on this
> particular item.
>
What item? The initialization thing? Its been a really long time so I don't
remember exactly what we did. We were using the XD-Ada compiler for the
Mil-Std-1750a. (Might also have been true of the MC680x0 target as well, but
I didn't test it on that path.) IIRC, we had a record type that was
initialized by default values. When you declared an object of that type, the
compiler generated subroutine calls for it to get it initialized. It was
causing speed problems, so we tinkered. Initializing it with an aggregate
instead (no default initial values for the type) got us down to the one-word
data move we wanted. Or maybe it was the other way around. :-) It *was* a
long time ago. But it illustrates that you can get very different code to
accomplish the same goal, so you really have to know your compiler, etc.


> Part of the GLOBAL thrust of what I'm doing is gearing myself up on Ada95,
> with the idea in the back of my head of tackling some things that are
> typically done in C/C++, and seeing if I can learn enough along the way to
> replicate your results in a different domain area: 2x productivity, 1/4x
> defect density.
>
You have to be real careful because there is always that all-important
caveat: YOUR MILEAGE MAY VARY!!! :-) In this particular realm, we had a very
specialized process and unlike most projects, we were frequently building
essentially the same thing over and over again. The kinds of errors we
encountered were really peculiar to the specific problem domain and wouldn't
necessarily apply across the board. Hence the productivity and defect rates
may not be anywhere near what someone else in another problem space would
realize. (You might even do better? Who knows?) Also, since we were
measuring a live process that was going on over maybe more than 10 years,
you didn't exactly have laboratory-grade isolation of just the language.
Other things were going on at the same time, so its hard to credit just Ada
for the improvements & have strong confidence that you could reproduce the
same result in another environment just by injecting a new language.


> Gotta do something to pass the time between job interviews and mailing out
> resumes and such.
>
I feel your pain. :-) Giving some thought to re-entering the fray once again
myself. Not a prospect I relish, but sometimes its the thing to do. Good
luck with it and I hope you find something where you can use & promote Ada.


> (The argument is something like this:  "Now, we all know that there really
> aren't any silver bullets, right?  There really aren't any magic wands you
> can wave, that will just like magic give you 2x productivity improvement
and
> 1/4x defect density, right?  We all know that, don't we?  Well, what if
> there was one?  Suppose there WAS such a wand, such a super secret magic
> bullet, that really would let you tackle your current project with half as
> many cars in the parking lot, that would let you write only 1/4 as many
bug
> reports and bug fix reports and retest reports.  If such a wand really did
> exist, would you ignore it, throw it away, bury it in a landfill and post
> armed guards 24/7 around it, or would you grab it and wave it for all you
> were worth?")
>

I understand and possibly agree - to a point. Its just that a lot more is
going to go into productivity and defects than just the language. Its that
bind of "All Other Things Being Equal" - which is almost never the case.
Sure, Ada (in the abstract sense) is better for building reliable software
quickly than is C. But what if C decides to cheat? If C gives you some huge
library of stuff that gets you 75% of the way out the door right now and
that library has been used/debugged extensively, and there is no equivalent
for Ada, will not C win? Or if the project is fairly short term and the
staff already knows C++ extensively and knows nothing about Ada, can Ada
win?

I believe Ada is better based on the evidence I've seen over the years. Its
just that the competition is seldom on an even playing field. The way around
that is for Ada to create its own playing field where the other languages
are at a disadvantage. We don't have to be "fair" or "nice" about it either,
do we? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com