Air Force shows how meaningless Ada waiver process is

Air Force shows how meaningless Ada waiver process is

[Rhoda Metzger]

    A recent Air Force article shows how meaningless the Ada Mandate is in
terms of providing an insurmountable obstacle to using anything other than Ada
for fielded systems: the Ada Mandate is always easily worked around by
experimental-to-fielded source code creep.

    The September 5 issue of Government Computer News has an article about an
Air Force developed system for airfield analysis called the Combat Readiness
Infrastructure Support Information System (CRISIS).  CRISIS was developed at
the Air Force Academy in the 1980s by some of the civil engineers there as a
way to make maps of the service's air fields and bases.

    The system is based on AutoCAD (a nice COTS system vis-a-vis Perry's
memo), with the MSDOS version using AutoLisp and Basic to provide the extra
functionality needed to support Air Force needs, and the Unix version being
extended with AutoLisp, C and C++ code, with links to external database
management systems.

    For peace time use, I suppose this violation of the Ada Mandate is
probably tolerable, but then the creep sets in.

    During Desert Storm, the Tactical Air Command used a beta version of
CRISIS to deploy forces in desrts of the Persian Gulf. By importing satellite
images of the area into AutoCAD, engineers were able to model airfields in
only a matter of minutes.  "When we started developing CRISIS, there was no
off-the-shelf software that could do what we needed.  Even now, there is
nothing as customized as CRISIS for the way the Air Force does things".

    Thus a rationale for getting around the Mandate. Develop something off the
waiver radars for a non-fielded application and then gradually introduce to
users in the field, which assuming the application has benefits, will slip
into fielded use with little concern about any non-Ada dependencies.  This
is not an isolated case.  SIGNAL magazine had an article a few months ago
about a similar creeping Air Force program now used in NORAD operations.
It's a shame no one writes clear memos for Air Force people that actually
mention Ada for advanced applications.

    What's worse is that these creeping success stories seem to figure out
how to do what Ada success stories can't - how to get published.

    Once again we see the myopia of DISA in continuing to reject the idea of
doing a comprehensive programming language use surver inside and outside the
DoD.  With such a survey, many of these creeping efforts can be nipped in the
bud and transitioned to Ada before it is too late.  Why DISA continues to
refuse to do such a survey defies Ada-supporter analysis.  And nothing in the
DualUse Plan addresses this detection issue.  If I can do it with no money,
they should be able to do it with all of the millions they have to spend.

Greg Aharonian

Re: Air Force shows how meaningless Ada waiver process is

[John R. Cobarruvias]

In article <CvtD8F.JHt@world.std.com>, srctran@world.std.com (Rhoda
Metzger) wrote:

>     A recent Air Force article shows how meaningless the Ada Mandate is in
> terms of providing an insurmountable obstacle to using anything other than Ada
> for fielded systems: the Ada Mandate is always easily worked around by
> experimental-to-fielded source code creep.
> 
[A LOT OF RHONDA METZGER'S POSTING, THAT LOOKED LIKE GREGS WEEKLY TRIPE,
DELETED]

> Greg Aharonian

OOPS...no wonder......

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    _/_/_/_/_/_/_/_/_/_/_/
~  John R. Cobarruvias              ~    _/        _/        _/
~  NASA-Johnson Space Center        ~              _/
~  Mail Code EK31                   ~  _/_/_/_/_/  _/  _/      _/
~  Hou, CITY OF CHAMPIONS TX 77058  ~  _/      _/  _/  _/_/  _/_/
~  713-483-9357, 713-483-4319 (fax) ~  _/_/_/_/_/  _/  _/  _/  _/
~  cobarruvias@asd1.jsc.nasa.gov    ~  _/      _/  _/  _/      _/
~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  _/      _/  _/  _/      _/
Gig Em Aggies                                      _/
1994 NBA CHAMPIONS, HOUSTON ROCKETS!           _/_/_/_/_/

Greg Annoyingme gets tricky (was: Re: Air Force shows how meaningless Ada waiver process is)

[Ted Dennison]

In article <CvtD8F.JHt@world.std.com>, srctran@world.std.com (Rhoda Metzger) writes:
|>     A recent Air Force article shows how meaningless the Ada Mandate is in
|> terms of providing an insurmountable obstacle to using anything other than Ada
|> for fielded systems: the Ada Mandate is always easily worked around by
|> experimental-to-fielded source code creep.
(a lot of suspiciously Greg Annoyingme-like prose)

|> Greg Aharonian


Ok. First Greg posts without his name, then he pretends to be "Rhoda Metzger".
Either someone is playing tricks on him (And if so, three cheers!) or he
is purposely doing this to get arround people's kill files.

T.E.D.

Re: Greg Annoyingme gets tricky (was: Re: Air Force shows how meaningless Ada waiver process is)

[John R. Cobarruvias]

In article <34nnqp$3c8@theopolis.orl.mmc.com>,
dennison@romulus23.DAB.GE.COM (Ted Dennison) wrote:

> In article <CvtD8F.JHt@world.std.com>, srctran@world.std.com (Rhoda Metzger) writes:
> |>     A recent Air Force article shows how meaningless the Ada Mandate is in
> |> terms of providing an insurmountable obstacle to using anything other than Ada
> |> for fielded systems: the Ada Mandate is always easily worked around by
> |> experimental-to-fielded source code creep.
> (a lot of suspiciously Greg Annoyingme-like prose)
> 
> |> Greg Aharonian
> 
> 
> Ok. First Greg posts without his name, then he pretends to be "Rhoda Metzger".
> Either someone is playing tricks on him (And if so, three cheers!) or he
> is purposely doing this to get arround people's kill files.

Looking at all the discussions taking place after greg's weekly stink bomb
posts, it seems like not enough have greg in a kill file. Greg drops a
weekly subject full of inaccuracies, accusations, etc, etc, and everyone
else carries the discussion for him weeks later.

I tell you, Greg's posts is like a person who expells gas on the 2nd floor
of an crowded elevator then leaves, and everyone left gripes about it all
the way up to the top. HEY FOLKS, GET OFF THE ELEVATOR!

(or hold your breath!)

> 
> T.E.D.

Re: Air Force shows how meaningless Ada waiver process is

[Richard A. O'Keefe]

srctran@world.std.com (Rhoda Metzger) writes:
>    A recent Air Force article shows how meaningless the Ada Mandate is ...
>Greg Aharonian

I don't *care*.  I don't give a flying rat's dropping for the Ada Mandate.
Could anyone who wants to argue either for or against US Governent Ada
policies please restrict their postings to 'usa', not 'world'.  The Ada
Mandate could only have hurt Ada companies if they had bet their businesses
on sales to the US Government and ignored the rest of the world.  If that's
what they did, then the problem is not the Mandate but parochialism.  The
Ada market _should_ be global, and the Mandate isn't.

-- 
The party that took Australia into Vietnam wants to smash the inner-city
yacht school and put a Grand Prix in its place.  They don't change.

Re: Air Force shows how meaningless Ada waiver process is

[Michael Feldman]

In article <353sdk$6vu@goanna.cs.rmit.oz.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.oz.au> wrote:
>srctran@world.std.com (Rhoda Metzger) writes:
>>    A recent Air Force article shows how meaningless the Ada Mandate is ...
>>Greg Aharonian
>
>I don't *care*.  I don't give a flying rat's dropping for the Ada Mandate.
>Could anyone who wants to argue either for or against US Governent Ada
>policies please restrict their postings to 'usa', not 'world'.  The Ada
>Mandate could only have hurt Ada companies if they had bet their businesses
>on sales to the US Government and ignored the rest of the world.  If that's
>what they did, then the problem is not the Mandate but parochialism.  The
>Ada market _should_ be global, and the Mandate isn't.

But the Ada companies _did_ bet their businesses on sales to the US 
government. That is exactly what this thread has been about, and goes
far in explaining why the good folks in Australia are stuck with the
same mediocre compilers, tools, and bindings as we are in the US.
It is exactly that parochialism that we all - including the folks in
other hemispheres - ought to be pestering these companies about. 

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
NOTE NEW PHONE NUMBER.
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------

Re: Air Force shows how meaningless Ada waiver process is

[Robert Dewar]

Mike, to your claim that Ada companies bet on sales to the DoD under the
Mandate. Poppycock! at least if you are talking about all companies. ALsys
was a French company which always had far more employees in France than
in the US, and concentrated on sales in Europe where there is no mandate.

Alsys has shifted its emphasis somewhat with the Telesoft merger, but I
would still be willing to bet that a big part of its revenue comes from
non-DoD sources (including such US customers as NASA and Boeing commercial).

As for the claim that the mandate is responsible for the perceived poor
quality of Ada tools (a broad brush characterization that is not at all
generally fair -- there are good Ada tools and bad Ada tools around), I
know this is a popular view from the vendor-bashers club of which you
seem to be one of the founding members, but apart from a lot of rhetoric,
I have never seen any convincing argument that this is the case.

In fact, you could well argue that the failure of vendors to generate
sufficient revenue to support continued improvement etc was due to the
mandate not being enforced well enough, although that's also a hard
after-the-fact argument to make convincingly.

There - that should start a nice thread of diatribe. Perhaps I should
have changed the subject line to something more flamboyant :-)

Vendor bashing? Sort of.

[Michael Feldman]

In article <35517g$8um@schonberg.cs.nyu.edu>,
Robert Dewar <dewar@cs.nyu.edu> wrote:
>Mike, to your claim that Ada companies bet on sales to the DoD under the
>Mandate. Poppycock! at least if you are talking about all companies. ALsys
>was a French company which always had far more employees in France than
>in the US, and concentrated on sales in Europe where there is no mandate.

OK, Alsys excepted. I still think it's pretty much the case that even
Alsys saw its competition as coming from other Ada companies, not other
languages. Conceivably they did not feel this way (I wasn't on the
inside of course), but to an outsider, they surely acted like it.
You may simply have been too close to those companies (at that time)
to see them as an outsider did. "Where you stand depends on where you sit."

>Alsys has shifted its emphasis somewhat with the Telesoft merger, but I
>would still be willing to bet that a big part of its revenue comes from
>non-DoD sources (including such US customers as NASA and Boeing commercial).

I think that's probably true.

>As for the claim that the mandate is responsible for the perceived poor
>quality of Ada tools (a broad brush characterization that is not at all
>generally fair -- there are good Ada tools and bad Ada tools around), I
>know this is a popular view from the vendor-bashers club of which you
>seem to be one of the founding members, but apart from a lot of rhetoric,
>I have never seen any convincing argument that this is the case.

Well, I guess you have to count me into the vendor-bashers. I can't say
whether it was the mandate _per se_ that inhibited the tools; maybe it
was just that these companies did not see who the real competition was,
and Alsys was looking over its shoulder (mostly) at Verdix and TeleSoft
(the same can be said for Verdix and TeleSoft) and not at the other
languages/environments. Not until they were too locked in to easily
extricate themselves.

Of course this is the view of an outsider - I'm not part of the "inner
circle" - and _certainly_ wasn't in the 83-90 timeframe. I can only
reason from actions.

>In fact, you could well argue that the failure of vendors to generate
>sufficient revenue to support continued improvement etc was due to the
>mandate not being enforced well enough, although that's also a hard
>after-the-fact argument to make convincingly.

I agree, though it is plausible. But I say again that seeing the DoD
as the primary market, and (I presume) soliciting investment on that 
basis and not on Ada's promise as a broader product, was the mistake.
It is easy to say this in hindsight, which is always 20-20. But I and
others were saying it back in 85-86-87 too, and we were dismissed with
a wave of the hand as being hopelessly out of touch. We actually predicted
pretty well what the outcome would be, considering that we were not on 
the inside. So who was out of touch? We were in fact thinking much bigger
than competing with just other Ada companies.

>There - that should start a nice thread of diatribe. Perhaps I should
>have changed the subject line to something more flamboyant :-)

I changed it.

As I said in a previous post: I will get off the vendors' case for good
if they step forward and say "OK, we blew it; where do we go from here?
you guys were at least partially right, so we are listening now." But
as you and I have discussed privately, there's not much chance of this
happening, because the vendors seem to spend much of _their_ time DoD-
bashing instead of opening up markets.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
NOTE NEW PHONE NUMBER.
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------

Re: Vendor bashing? Sort of.

[Mitch Gart]

Michael Feldman (mfeldman@seas.gwu.edu) wrote:

: OK, Alsys excepted. I still think it's pretty much the case that even
: Alsys saw its competition as coming from other Ada companies, not other
: languages. Conceivably they did not feel this way (I wasn't on the
: inside of course), but to an outsider, they surely acted like it.
: You may simply have been too close to those companies (at that time)
: to see them as an outsider did. "Where you stand depends on where you sit."

Unfair.  During the 80's Alsys did a lot of promotions, conferences,
ads, and so on trying to get Ada to catch on with non-defense users.
They developed compilers for environments that were not seen at the 
time as being big DOD markets, such as the PC and IBM mainframes.
Once they even paid for a focus group where they got a bunch of IS
managers in and asked them why they use the languages they do,
what features they need from a computer language, what it would 
take to get them to change languages, that sort of thing.

With hindsight, these efforts could possibly be criticized as being 
unsuccessful, or incorrectly implemented for one reason or another.  
But you can't say they didn't try, because they really did invest lots 
of time and money over several years.  

	Mitch Gart

Re: Air Force shows how meaningless Ada waiver process is

[Christopher Costello]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: Mike, to your claim that Ada companies bet on sales to the DoD under the
: Mandate. Poppycock! at least if you are talking about all companies. ALsys
: was a French company which always had far more employees in France than
: in the US, and concentrated on sales in Europe where there is no mandate.

not quite true - in Europe the military (including NATO) have
policies regarding Ada. Someone more in the know might be able
to say whether these are more or less stringent than the US "mandate"

: Alsys has shifted its emphasis somewhat with the Telesoft merger, but I
: would still be willing to bet that a big part of its revenue comes from
: non-DoD sources (including such US customers as NASA and Boeing commercial).

: As for the claim that the mandate is responsible for the perceived poor
: quality of Ada tools (a broad brush characterization that is not at all
: generally fair -- there are good Ada tools and bad Ada tools around), I
: know this is a popular view from the vendor-bashers club of which you
: seem to be one of the founding members, but apart from a lot of rhetoric,
: I have never seen any convincing argument that this is the case.

: In fact, you could well argue that the failure of vendors to generate
: sufficient revenue to support continued improvement etc was due to the
: mandate not being enforced well enough, although that's also a hard
: after-the-fact argument to make convincingly.

: There - that should start a nice thread of diatribe. Perhaps I should
: have changed the subject line to something more flamboyant :-)


--
+--------------------------------------------------------------------------+
| SIEMENS   Christopher Costello   Tel:    +49 89 636 40367                | 
| =======   SNI BU BA NM 123       Fax:    +49 89 636 45860                | 
| NIXDORF   Muenchen, Germany      E-mail: Christopher.Costello@mch.sni.de |
+--------------------------------------------------------------------------+

Re: Vendor bashing? Sort of.

[Mike Ryer]

Just one additional point that bears on this discussion:  The existance of
the DOD Ada mandate may have attracted more companies to invest in Ada than
otherwise would have.  In the early days, there were at least ten separately
maintained root compiler technologies.  The Ada market has never been big
enough to maintain that many different front-end/optimizer/runtime 
frameworks.  If there had been no mandate, perhaps only one or two companies
would have invested in Ada compilers, each getting a bigger share and
having more money for continuing engineering, PR, university outreach, etc.
If the mandate had been enforced, there might have been enough business
to let all ten or so companies do everything right technically and in
the market.  Venture capital would be easier to get, and "Ada is good" 
advertising would be easier to justify if there were fewer competitors.
DOD's in-between position of claiming that there would be a mandate
but not really doing it increased the risk in everyone's investement.

Of course, there are a lot fewer vendors now, and rumor has it that the
newly-merged companies are cutting down to one core technology each.

In a classical create-a-market scenario, there is a single company that
owns the product and will get all of the revenue from the newly expanded
market.  When ten companies have the same idea at once, nine of them should
drop out :-)

The pet rock business is different from the socket wrench business.  People
who are good at one are not too likely to be good at the other.  I'm sort
of pleased that the engineers around here don't *want* to make pet rocks.

Still, here's my latest marketing gimmick.  Tell everyone you know:

     "Don't worry, there will be plenty of C maintenance work for
      those programmers who can't learn Ada".

Mike Ryer
(speaking only for myself

Re: Vendor bashing? Sort of.

[Robert Dewar]

Note also that the complaints about pricing of Ada products have also often
been made with a very narrow viewpoint (i.e. what C costs). In fact decent
COBOL compilers for example, with tools, have always cost about $3000 on
the PC, and still do!

It is true that C brought down the price level for compilers in general (and
in the process made it VERY difficult for anyone to make money making
compilers for anything -- there are a lot of good C compilers scattered
by the roadside!)

I think the main reason that (some) Ada tools were not better was simply
a lack of resources, so when Mike complains that the vendors blew it by
not providing better tools, he has to have an idea of where the resources
would have come from. There are two possibilities:

o  Vendors spent money on something else, which they should not have
This is hard to see, Mike if you think this, what do you have in mind.

o  If only Ada had been pricede at $100 (or some other low figure), the market
was so elastic (elasticity >> 1.0) that they would have made a ton of money
and been able to fund all sorts of stuff. If you believe that you are in my
opinion a card carrying member of the land of Oz, or some other fantasy world.

In fact there was a relatively huge amount of capital injected into the
Ada market, some of which did indeed generate some very good tools (e.g.
the support of hardware emulators that Alsys provides, or the Rational
APex environment), and my guess is that the *only* reason that this money
was available was the mandate. A possible exception is the support of
French banks for Alsys, which might well have been based on being sold
more generally on the future of Ada [of course the banks lost all their 
money, so in retrospect, they certainly made a bad investment decision].

My own view is that the critical thing is for Ada NOT to rely on inventing
its own tools, but instead to concentrate on being able to take advantage
of tools for other languages that already exist. Now with my GNAT hat on,
one of the very important aspects of GNAT is that its compilation model,
an commitment to system standards (calling sequences, debugging information,
object module formats etc) make taking advantage of existing tools a lot
easier, and I would certainly like to see other Ada compilers move in the
same direction (good ideas in GNAT are free for the taking. A number of
vendors are still afraid of even reading GNAT sources because they are
afraid of contaminating themselves by doing so -- that's silly, but there
is only so much effort that I am willing to put in trying to convince other
vendors to take advantage of GNAT in this way :-) Incidentally, this doesn't
apply to all vendors, some of whom are looking VERY closely at GNAT and
definitely copying our ideas, which we find most pleasing. [I know that
sounds strange to people more accustomed to locking up their sources in
a safe with armed guards, but free software is another world!]

Re: Vendor bashing? Sort of.

[Robert Dewar]

Mike Ryer points out that the Ada mandate perhaps encouraged too many
basic technologies to be developed, and guesses that with no mandate,
there might have been a smaller more reasonable number. I am afraid
that number might well have been zero (consider as an example Algol-68 or
many other languages designed since then).

Re: Vendor bashing? Sort of.

[Michael Feldman]

In article <Cw4FKr.3p5@inmet.camb.inmet.com>,
Mitch Gart <mg@asp.camb.inmet.com> wrote:

>Unfair.  During the 80's Alsys did a lot of promotions, conferences,
>ads, and so on trying to get Ada to catch on with non-defense users.

Well, I said I'd be happy to stand corrected, so thanks for correcting
this impression. Certainly Alsys managed to keep themselves a pretty
good secret from university professors like myself. Indeed, an Alsys
principal once told me Alsys was simply not interested in dealing with 
universities. 

I think the reason given was piracy. I responded that
(in the days when you had to buy the bundled PC memory board) nobody
could use the compiler except someone who'd bought the memory too.
I also mentioned that I knew very few students with Vax-en in their
dorm rooms, so did they really think Vax compilers would be pirated? 
To where? There was never much an answer to this.

Of course, it was their business decision to make, and I'm happy they 
finally reversed it in 1991. 'Course the SEED program, nice as it is,
is quite difficult to get information about, or rather information is
available only sporadically, 'cause the person responsible for it keeps
changing and has tended to give it low priority. Each year, a couple of
months before SIGCSE, we have tried to get them to focus on sending
us (SIGAda EdWG) an updated price list for distribution at our booth.
It was tough going, and a couple of years we ended up with nothing.

>They developed compilers for environments that were not seen at the 
>time as being big DOD markets, such as the PC and IBM mainframes.

Hmmm - I seem to recall that about the time that the IBM mainframe
system came out, FAA was using MVS boxes in the air traffic redesign.
Could this have been part of the motivation for the mainframe port?

(I thought it was VERY innovative, by the way, that Alsys developed
a PC-host, mainframe-target cross compiler. It turned the classical
cross-compiler perception on its head. The ONLY place I ever heard
mention of this - other than the line in the validation list - was
inside IBM Federal, where I had some friends.)

As for the PC compiler, I recall when FirstAda was announced, with great
fanfare, and the price was set at Ada's birth year, "only" $1815. Not
exactly the kind of price the mass market can afford to pay.

>Once they even paid for a focus group where they got a bunch of IS
>managers in and asked them why they use the languages they do,
>what features they need from a computer language, what it would 
>take to get them to change languages, that sort of thing.

So what was the outcome? Don't keep us in suspense...

>With hindsight, these efforts could possibly be criticized as being 
>unsuccessful, or incorrectly implemented for one reason or another.  
>But you can't say they didn't try, because they really did invest lots 
>of time and money over several years.  

OK, I stand corrected. It was not terribly obvious at the time, at
least not in the States. Maybe it was more so in Europe?

I really don't want to continue in this negative vein. We are all
clearly in a bit of a mess now. Where do we go from here? Just
bashing the government for blowing it on the mandate, and for
supposedly making Ada 9X "too big" (though of course nobody wants
_their_ features deleted...) will not get us very far. What next?

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
NOTE NEW PHONE NUMBER.
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------

Re: Vendor bashing? Sort of.

[Gregory Aharonian]

>I really don't want to continue in this negative vein. We are all
>clearly in a bit of a mess now. Where do we go from here? Just
>bashing the government for blowing it on the mandate, and for
>supposedly making Ada 9X "too big" (though of course nobody wants
>_their_ features deleted...) will not get us very far. What next?
>
>Mike Feldman

    Simple.  Change DoD procurement regulations to give contractors incentives
to be as cost effective as possible.  Hard to sell (and build an Ada business)
to contractors who make the same amount of money as long as their performance
is not completely attrocious.  I would be happy to live with every idiotic
Ada policy out there if the DoD would just change its procurement regulations
to be more compatible with market practices.
    Example.  I once had a chance to help save a DoD contractor a few hundred
thousand dollars on a project they were working on by providing them with 
existing Ada code (instead of them having to write it from scratch).  My
charge would have been a few tens of thousands of dollars.  So the DoD saves
money, the contractor completes the contract quicker, and I make some more
money to live and invest in my Ada business.
    Unfortunately, the managers there weren't interested for two reasons.
First they wouldn't give their workers a charge number for one hour of time
for me to come in and make a presentation.  I don't mind being rejected after
you have heard my pitch, but at least let me make it.  Second, their bonuses
and company profits were fixed to a percentage of the contract size, so my
offer to save money translated in their heads to less bonus and profits, an
instant sales killer.
    All this talk about commercializing Ada is utterly pointless, like the
current DualUse plan, as long as these conditions prevail.  For the only way
new companies are goign to find the money to commercialize Ada in the
non-Mandated world (where the market is miniscule) is from the profits made
in the Mandated world.  But for ten years, other than for compiler sales,
this is been impossible.

    In fact, here is another statistic to be collected:  what is the annual
sales of reusable Ada components from businesses into the Mandated world,
as a fraction of DoD software procurement expenditures?

Greg AHaronian

Re: Vendor bashing? Sort of.

[Michael Feldman]

In article <359i6o$lja@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Note also that the complaints about pricing of Ada products have also often
>been made with a very narrow viewpoint (i.e. what C costs). In fact decent
>COBOL compilers for example, with tools, have always cost about $3000 on
>the PC, and still do!

Which is, I suppose, why COBOL is tremendously popular on PC's. :-)

On the other hand, as you've pointed out before, Realia COBOL (rather,
a version thereof) is shrink-wrapped inside a seemingly popular COBOL text.
Is this book used widely in community colleges and other places where
COBOL is taught?

In looking at C texts the other week, I found at least three with shrink-
wrapped compilers; more if you include C++ texts. One is WATCOM, whose
professional version has gotten good reviews in the C mags; one is
MIX, for years the cheapest "real" C I could ever find, perfectly
acceptable for students; the third is Zortech, recently taken over
(if memory serves) by Symantec. All three books were priced at
about $40.00, which is about the same price as other "thick" C books
with no software.

The only Ada compiler available in text-shrinked form is AETech's,
which can be had in a version of Nick DeLillo's book. I think the suggested
list price is $69.95, which is double the price of the same book without
the compiler. I have shopped a lot of technical bookstores, and often
see Nick's book there, but have _never_ seen the version with the
compiler included. In fact, I thought it was vaporware, but finally got
a copy direct from the publisher (after some prodding). We're not talking
5 years ago, folks, but _right now_.

>It is true that C brought down the price level for compilers in general (and
>in the process made it VERY difficult for anyone to make money making
>compilers for anything -- there are a lot of good C compilers scattered
>by the roadside!)

True. Some of them are shrinkwrapped into $40.00 texts!
>
>I think the main reason that (some) Ada tools were not better was simply
>a lack of resources, so when Mike complains that the vendors blew it by
>not providing better tools, he has to have an idea of where the resources
>would have come from. There are two possibilities:
>
>o  Vendors spent money on something else, which they should not have
>This is hard to see, Mike if you think this, what do you have in mind.

I have stated before that IMHO the Ada companies invested far too much
resources into "me-too" ports. Each code generator costs money; each 
validation costs money; supporting zillion low-volume ports costs money.
At one point a couple of years ago, checking the AdaIC compiler list
revealed ten VMS/VMS compilers and (I think it was) nine Sun3/Sun3
compilers.  For a while I thought "Wow! What great competition!"
but later changed my view to "Gawrsh, they are spreading themselves
thin!"

Each vendor (apparently) thought it had to compete head-to-head with
all the others on _every_ major platform. It seemed absurd to me -
it may have been naive of me to think that the vendors would, de facto,
segment the market more. I cannot believe that each of the 40-50
validated versions from the major vendors paid its way.

I don't know how much more successful Tartan and DDC-I have been with
their more sharply targeted ports. And of course these are not really
tool companies.

>o  If only Ada had been pricede at $100 (or some other low figure), the market
>was so elastic (elasticity >> 1.0) that they would have made a ton of money
>and been able to fund all sorts of stuff. If you believe that you are in my
>opinion a card carrying member of the land of Oz, or some other fantasy world.

Dunno - we can speculate endlessly about this; I don't think either of us
will have a mnopoly on the truth here.

>In fact there was a relatively huge amount of capital injected into the
>Ada market, some of which did indeed generate some very good tools (e.g.
>the support of hardware emulators that Alsys provides, or the Rational
>APex environment), and my guess is that the *only* reason that this money
>was available was the mandate. 

Your guess is as good as mine; rather, mine is as good as yours.
Mine is that if Ada had been portrayed to investors as a _really_ dual-use
technology, even more money might have been there (in the days before
1987-88 or so, when the C++ bandwagon really started rolling).

>A possible exception is the support of
>French banks for Alsys, which might well have been based on being sold
>more generally on the future of Ada [of course the banks lost all their 
>money, so in retrospect, they certainly made a bad investment decision].

I haven't the foggiest idea what happened there. 

>My own view is that the critical thing is for Ada NOT to rely on inventing
>its own tools, but instead to concentrate on being able to take advantage
>of tools for other languages that already exist. 

Hindsight is always 20-20, of course, but doing this - and also developing
e.g. friendlier interfaces to Fortran, to penetrate engineering - might
have been a good idea even 5-6-7 years ago. If any of this was tried,
I certainly did not see it. There was a definite sense that everyone
Ada was _different_ and had to live in its own little world. 

Also, I think more vendor "moral support" for free software, especially
in the bindings area, where no vendor-proprietary stuff needed to be
included, would have creating a rising tide that floated everyone's
boat. Instead, we even had proprietary _math libraries_ for Heaven's
sake! Surely the vendors could've all glommed onto one of the de facto
standard ones, and quietly made sure that it was portable and optimized.
That would've saved a lot of resources - let someone else do the work!

This could've been done in a neutral forum like the SIGAda working groups;
I don't think it really happened, though. (A lot of work was done in
the WG's, but I don;t know whether any of it was filtered back into
the compiler distributions. I don't think so, but will be glad to
stand corrected.

>Now with my GNAT hat on,
>one of the very important aspects of GNAT is that its compilation model,
>an commitment to system standards (calling sequences, debugging information,
>object module formats etc) make taking advantage of existing tools a lot
>easier, and I would certainly like to see other Ada compilers move in the
>same direction (good ideas in GNAT are free for the taking. A number of
>vendors are still afraid of even reading GNAT sources because they are
>afraid of contaminating themselves by doing so -- that's silly, but there
>is only so much effort that I am willing to put in trying to convince other
>vendors to take advantage of GNAT in this way :-) 

I rest my case. Some of them still don't get it, I guess.

>Incidentally, this doesn't
>apply to all vendors, some of whom are looking VERY closely at GNAT and
>definitely copying our ideas, which we find most pleasing. [I know that
>sounds strange to people more accustomed to locking up their sources in
>a safe with armed guards, but free software is another world!]

And it's a world that the vendors can either work at exploiting to their
advantage, or oppose to their death. There are lots of ways to glom onto
GNAT; it takes some creative thought, though. I hope the vendors have
got some creative people in their shops...:-)

[Just last night I got yet another e-mail missive from a vendor principal,
opining that GNAT is unfair competition. I will not identify the vendor,
but note that the company in question would benefit, IMHO, from glomming
onto GNAT instead of fighting it.]

Lest I be accused of "bashing" again, all of this stuff I've been writing
has been not to point the finger of blame, but rather to see if we can
learn some lessons, so that we get it right the second time. Simply
reacting to the identification of problems by calling it "vendor bashing"
will not move us forward. Owning up to the problems will get us in the 
right direction (at least I hope so).

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
NOTE NEW PHONE NUMBER.
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------

Quo Vadis Ada Market?(was Re: Vendor bashing? Sort of.)

[david.c.willett]

From article <SRCTRAN.94Sep16091638@world.std.com>, by srctran@world.std.com (Gregory Aharonian):
> 
>	{Greg responds to Mike Feldman's "Where to from here?"}

	Greg, this is a cogent and thoughtful post.  It might provoke
	some real change.  I consider it much more effective that 
	the tantrums you have visited upon us in the past.
 
>     Simple.  Change DoD procurement regulations to give contractors incentives
> to be as cost effective as possible.  Hard to sell (and build an Ada business)
> to contractors who make the same amount of money as long as their performance
> is not completely attrocious.  I would be happy to live with every idiotic
> Ada policy out there if the DoD would just change its procurement regulations
> to be more compatible with market practices.

Since WWII, the DoD procurement regulations have been based on the patronage
model, not the free market one.  The principal reason was the Cold War need
to "push the technical envelope" in the arms race, as well as preserve a 
rapidly expandable industrial base which the civilian market could not 
be relied upon to support.  Recall that the US had considerable difficulty
gearing up a wartime economy in 1941, despite the fact that we had 
been producing war materiel for the British since (approximately) 1936.
Until 1991, the geo-political climate suggested that the US could be 
fighting a major land war in Europe on a week's notice.

>     Example.  I once had a chance to help save a DoD contractor a few hundred
> thousand dollars on a project they were working on by providing them with 
> existing Ada code (instead of them having to write it from scratch).  My
> charge would have been a few tens of thousands of dollars.  So the DoD saves
> money, the contractor completes the contract quicker, and I make some more
> money to live and invest in my Ada business.
>     Unfortunately, the managers there weren't interested for two reasons.
> First they wouldn't give their workers a charge number for one hour of time
> for me to come in and make a presentation.  I don't mind being rejected after
> you have heard my pitch, but at least let me make it.  Second, their bonuses
> and company profits were fixed to a percentage of the contract size, so my
> offer to save money translated in their heads to less bonus and profits, an
> instant sales killer.

Uh-huh.  This experience is the direct economic result of the industrial 
base considerations I mentioned above.  The ability to produce lots of 
<insert weapon here> should we need to was just as valuable as reducing
the cost of producing a few <insert weapon here>.

>     All this talk about commercializing Ada is utterly pointless, like the
> current DualUse plan, as long as these conditions prevail.  For the only way
> new companies are goign to find the money to commercialize Ada in the
> non-Mandated world (where the market is miniscule) is from the profits made
> in the Mandated world.  But for ten years, other than for compiler sales,
> this is been impossible.

Ahh, but the fudamental rules are changing.  The US no longer faces the 
threat of global war, but instead faces the threat of many mini-wars.
This brings the DoD market more in line with its civilian counterpart.
The cost-effectiveness of small batches of <insert weapon here> becomes
important.  Maybe if one views the situation as *one* Ada market of some 
particular size rather than two (one Mandated of appreciable size; one 
much smaller, non-Mandated market) one can market more effectively.
As I see it, we are currently in a period of transition between the 
two regimes and the principal impediment we face is the inertia of 
the old guard.

> 
>     In fact, here is another statistic to be collected:  what is the annual
> sales of reusable Ada components from businesses into the Mandated world,
> as a fraction of DoD software procurement expenditures?
> 
> Greg AHaronian
>
 
<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Dave Willett          AT&T Advanced Technology Systems
                      Greensboro, NC USA

When short, simple questions have long, complex answers -- your 
organization's in trouble.

	Adapted from "In Search of Excellence"

Re: Vendor bashing? Sort of.

[Robert Dewar]

Greg, let me get this right, you wanted to charge for an hour of time to
come in and make a sales pitch? Well that's a novel way of doing business
(well perhaps one should say it would be novel if it worked). Charging
for sales pitches, well, well, that's the second strangest thing I heard
about today (the first is too long a story ...)

Re: Air Force shows how meaningless Ada waiver process is

[Fred McCall]

In <35517g$8um@schonberg.cs.nyu.edu> dewar@cs.nyu.edu Robert Dewar writes:

>As for the claim that the mandate is responsible for the perceived poor
>quality of Ada tools (a broad brush characterization that is not at all
>generally fair -- there are good Ada tools and bad Ada tools around), I
>know this is a popular view from the vendor-bashers club of which you
>seem to be one of the founding members, but apart from a lot of rhetoric,
>I have never seen any convincing argument that this is the case.

Well, having worked with a number of tools (and currently working with
what are probably top-end Ada tools -- at least they cost enough), I
have to agree in part with the 'vendor bashers'.  I've found the quality
of tools to be lower than comparable ones for other languages, as well
as being more expensive.  Compiler messages are cryptic (I expect a lot
more informative messages -- if the language is going to be that picky
and try to force safe practices, the compilers ought to know a lot more
than mine is telling me when an error is found).  Development tools are
buggy and/or difficult to use.  *EVERYTHING* requires more in the way of
resources (including money).  I consider all of this as fall-out from
having a captive audience.  

The Ada Mandate should go.

[No, I'm not going to mention the vendors, except to say that they are
aware of our discontent and seem very interested in trying to address
our problems.  But then, we're talking about a *lot* of money.]

>In fact, you could well argue that the failure of vendors to generate
>sufficient revenue to support continued improvement etc was due to the
>mandate not being enforced well enough, although that's also a hard
>after-the-fact argument to make convincingly.

I'm afraid I find that to be a pretty sad argument, period.  If the only
way that Ada companies could generate sufficient revenue to produce
reasonable tools and support was to have a market that was forced to pay
whatever they asked, regardless of the quality of the tools, then all I
can say is that the language itself has not made a case for its use.

Pascal managed fairly nicely.  Where was their captive market?  C seems
to have done ok, after a somewhat slow start (along with UNIX).  Where
was their captive market?  C++ seems to have taken right off.  Where was
their captive market?

Lots of languages have managed to succeed without a captive market.
Lots have also managed to fail (or only establish niche markets).  If
Ada is the right language to use (after having evaluated all the
technical and cost factors), then that's what people should use.
However, if it's not, then people should be free to use the best, most
cost effective solution.  

If Ada is that solution (over the lifecyle), then SOMEONE IS GOING TO
ACTUALLY HAVE TO DEMONSTRATE THAT.  I've read both the original Ada vs.
C 'studies' and more recent Ada9X vs C++ 'remarks' (I don't think
they're detailed enough or fact-based enough to call them 'studies') and
I still don't find that Ada has made its case.  It all reads as if a
language proponent were writing propaganda.

It's real simple.  Dump the Ada mandate and we'll find out.  I think the
language has been protected long enough.

[Note that Europe is probably going to come up with a different answer.
After all, they liked Algol, too, but it wasn't exactly a rousing
success on this side of the pond.]


--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
---------------------------------------------------------------------------
merlin@annwfn.com -- I don't speak for others and they don't speak for me.

Re: Vendor bashing? Sort of.

[Gregory Aharonian]

>Greg, let me get this right, you wanted to charge for an hour of time to
>come in and make a sales pitch? Well that's a novel way of doing business
>(well perhaps one should say it would be novel if it worked). Charging
>for sales pitches, well, well, that's the second strangest thing I heard
>about today (the first is too long a story ...)

Robert,
	Obviously you are unfamilar with DoD contracting procedures, which
is why you fail to appreciate how business-suffocating many Ada policies
are.  I did not mean (and if you bothered to read what I posted) to demand
to be paid for making a sales pitch.  Maybe that's what's expected at NYU,
but not here in Boston. I think your knee-jerking is getting out of control.


	Each and every hour of a DoD contractor's employees day has
to be accounted for to some contract (unless he is a non-peon on overhead).
This is much like lawyer's who have to bill every hour of their day to one
of their clients.  Thus for someone at a DoD contractor to goto the library
for an hour to look up information on Ada, that person has to charge that
hour to some contract, or he or she won't be able to go.  For if each hour
is not accounted for to some contract, and legitimately, then the DoD auditors
from the DCAA (or whatever it is called now) get real nasty (well only if 
they detect lots of inconsistencies).

	So when I wanted to make a pitch to help one such company save money
by using some Ada software I had referenced in my databases, for anyone at
that company to sit in on a presentation I wanted to give, they would have to
get permission from their manager to charge to some DoD contract their spending
one hour to listen to me.  In this case, the manager refused to do so, so
despite having a group of programmers interested in what I could offer for as
an Ada entrepreneur, I could not even get a chance to make my pitch.
	Why did the manager refuse?  As I said before, using my services would
have allowed them to save the taxpayers and the DoD lot of money on the
contract, but would have cut into the company's and manager's profits and
bonuses, under existing defense procurement regulations.  So why bother
listening to a sales pitch, no matter how relevant.

	In general, this happens all over the Ada world and is one of the 
main killers of third party Ada businesses.  Ada is a language designed to
help people save money over the software life cycle being thrown at DoD
contractors who have little incentives to save money over the software life
cycle.  

	Every three years or so this issue comes up in a public way, and then
gets ignored once again.  But until it is addressed, Ada commercialization is
impossible.  Without a chance to earn profits in the Mandated world to invest
into pushing Ada into the non-Mandated world, no one new is going to be
attracted to the DoD's DualUse activities, even if they were practical.

	I mean, where does the DoD expect the investments to come from to see
their DualUse plans succeed?  The lack of any financial figures in DISA's
DualUse plan is indicative of the lack of support by the DoD in funding new
Ada initiatives (especially with the tens and hundreds of millions it gives
to ARPA to commercialize everythign but Ada).  So DoD investments.  The Ada
vendors and contractors should little sign of investing the tens of millions
of dollars needed, for the same reason that venture capitalists won't make
such investments - any money invested in Ada could return much, much larger
profits if invested in C++ or Visual Basic.  So where else is the DualUse
investments going to come from?  One place would be from profits selling
into the Mandated world, but the procurement regulations (as above) get in
the way.

Greg Aharonian

Re: Vendor bashing? Sort of.

[Michael Feldman]

In article <359ia6$lkj@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Mike Ryer points out that the Ada mandate perhaps encouraged too many
>basic technologies to be developed, and guesses that with no mandate,
>there might have been a smaller more reasonable number. I am afraid
>that number might well have been zero (consider as an example Algol-68 or
>many other languages designed since then).

Naturally, we can all speculate forever on this point. But I find it one
of the more bizarre I've seen lately. If, indeed, Ada was a solid and
sound design for its times, why on earth would nobody have been willing
to invest in its development, even if the DoD did not sound like it would
mandate use?

C++ chugged out of AT&T as a preprocessor, with no mandate; obviously 
companies have invested in it anyway, even before the juggernaut started 
rolling (and in fact, the investment is part of what is keeping the juggernaut
rolling).

In its day, Modula-2 was supported by a number of vendors, with no mandate.
True, Modula-2 is smaller than Ada. True, Wirth made the source code
for an early implementation available for commercialization, for $1000.,
I think it was.

Modula-3 is starting to catch a bit, starting as nothing more than a
joint research project of DEC and Olivetti. It's not quite as big as
Ada (I guess), but gettin' there.

Who invested in Betrand Meyer's Eiffel? Surely some money folks thought
it was a good idea. Bertrand must have been a good salesman. And Eiffel,
around for about 10 years, is starting to come into its own, along with
Smalltalk (which had Xerox behind it, not a mandate). Ada 94 can 
certainly compete with these quite well. These three - Eiffel, M3,
and Smalltalk offer many companies an alternative to C++, which they
are starting to crave. Ada 94 could be a player, but won't be until
it's more than vaporware (I know, GNAT...)

So how come investment money is available for these and not for Ada?
What are Bertrand Meyer and Adele Goldberg and the M3 folks doing right
that we are not doing? Who is backing them?

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
NOTE NEW PHONE NUMBER.
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------

Re: Vendor bashing? Sort of.

[Robert Dewar]

"Naturally, we can all speculate forever on this point. But I find it one
of the more bizarre I've seen lately. If, indeed, Ada was a solid and
sound design for its times, why on earth would nobody have been willing
to invest in its development, even if the DoD did not sound like it would
mandate use?"

Yes, well there are two big mistakes that non-business oriented technical
people make. First, they think that being technically best is a guarantee
of success, and second, they think that not being technically best is a
recipe for failure. Mike, there are dozens of companies around that have
been destroyed by technically oriented management that did not understand
how relatively unimportant technical superiority ranks on the scale of
things.

Such matters as perceived and actual levels of support, estimation of
financial soundness of the companies involved, size of the companies
involved, time to market, etc. etc often play a much larger role.

If you think of Modula-2 and Modula-3 as commercial successes which you
are sad that Ada was not able to emulate, then you really have a peculiar
view of the market. 

Mike, there is an easy experiment you can perform now. See if you can
get any venture capitalist to put up money to support work on Ada 9X.
All I can say is good luck if you try this! To be fair, you should inform
the venture capitalists that you do not expect the mandate to be maintained,
and they should discount the effect of the mandate in estimating the future
market potential of Ada. 

I am certainly not saying that you can succeed with rubbish products, no
matter how good other things look (consider IBM's failures with the
PC Jr and the RT as illustrations of this). Equally, there are cases where
a product really *does* succeed on technical excellence alone, but they
are few and far between.

Re: Vendor bashing? Sort of.

[Ted Dennison]

In article <35dc8e$t7h@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar) writes:
|> Greg, let me get this right, you wanted to charge for an hour of time to
|> come in and make a sales pitch? Well that's a novel way of doing business
|> (well perhaps one should say it would be novel if it worked). Charging
|> for sales pitches, well, well, that's the second strangest thing I heard
|> about today (the first is too long a story ...)
|> 

Actualy, Greg said:
"...First they wouldn't give their workers a charge number for one hour of time
for me to come in and make a presentation."

Note the word WORKERS. In my company, as well as most other large defence 
contractors I'm sure, we grunts are not allowed to do ANYTHING for one hour
without a charge number for it. I seriously doubt even Greg is stupid enough
to charge companies for sales pitches.

Greg is absolutely right that trying to pitch cost savings to a "cost +"
program at this stage is a waste of time. He should have hit them up when
they were BIDDING for the contract. That's when they would have been hungry
for cost savings (or even the appearance of cost savings). This was just a
dumb business decision on his part.

T.E.D.

Disclaimer: Martin Marietta has no opinon whatsover about Greg or his business
acumen. If they did, they'd buy him.

Re: Vendor bashing? Sort of.

[david.c.willett]

From article <SRCTRAN.94Sep18090214@world.std.com>, by srctran@world.std.com (Gregory Aharonian):
> 
>>Greg, let me get this right, you wanted to charge for an hour of time to
>>come in and make a sales pitch? Well that's a novel way of doing business
>>(well perhaps one should say it would be novel if it worked). Charging
>>for sales pitches, well, well, that's the second strangest thing I heard
>>about today (the first is too long a story ...)
> 
> Robert,
> 	Obviously you are unfamilar with DoD contracting procedures, which
> is why you fail to appreciate how business-suffocating many Ada policies
> are.  I did not mean (and if you bothered to read what I posted) to demand
> to be paid for making a sales pitch.  Maybe that's what's expected at NYU,
> but not here in Boston. I think your knee-jerking is getting out of control.
> 
> 
> 	Each and every hour of a DoD contractor's employees day has
> to be accounted for to some contract (unless he is a non-peon on overhead).
> This is much like lawyer's who have to bill every hour of their day to one
> of their clients.  Thus for someone at a DoD contractor to goto the library
> for an hour to look up information on Ada, that person has to charge that
> hour to some contract, or he or she won't be able to go.  For if each hour
> is not accounted for to some contract, and legitimately, then the DoD auditors
> from the DCAA (or whatever it is called now) get real nasty (well only if 
> they detect lots of inconsistencies).
>

Greg,
	Let's get some perspective on this, okay?  The DoD operates under
a set of regulations called the Federal Acquisition Regulations (FARs).
These regulations specify auditing standrards, accounting practices, 
authority for work rules, etc.  Companies are expected to implement 
practices that comply with the FARs and various auditing bureaus 
within DoD (e.g. Defense Contract Administration Agency -- DCAA --
and others) monitor contractors for compliance.

Note -- For old timers, I'm just pointing out the first couple 
     layers of a Bysantine system here.

As far as I know, DCAA's only interest is to see that the US Govt. 
isn't charged for things that were not to its benefit.  That is 
to say, that charges against a contract which could not be supportted 
under that contract's Statement of Work (SOW) are not allowed.  
To the best of my knowledge, the DCAA and the DoD have no interest 
in accounting for every moment of a worker's time, only in getting 
good value for their money.  This means (upper case for emphasis here)

	THE CONTRACTOR, NOT DOD, IS THE ONE INSISTING THAT 
	EMPLOYEES BILL THEIR TIME TO A CONTRACT.

In other words, Greg, your beef isn't with the DoD, but with the 
contractors you are trying to sell to.  It is, in fact, the 
very "understanding of economics" that you claim DoD lacks,
in action.  These companies don't think what you have to 
say is worth enough for them to "spend their own money" 
to listen to you.  Seems to me you don't have much of a case.

<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Dave Willett          AT&T Advanced Technology Systems
                      Greensboro, NC USA

When short, simple questions have long, complex answers -- your 
organization's in trouble.

	Adapted from "In Search of Excellence"

 

Re: Vendor bashing? Sort of.

[Kent Mitchell]

Gregory Aharonian (srctran@world.std.com) wrote:

[stuff deleted slamming Robert]
: 	Each and every hour of a DoD contractor's employees day has
: to be accounted for to some contract (unless he is a non-peon on overhead).

This is *not* true.  This may be what you think but all DoD contactors that
I work with are more than willing to have people educated and they do not
see any need to have this time billed against some contact.

: 	So when I wanted to make a pitch to help one such company save money
: by using some Ada software I had referenced in my databases, for anyone at
: that company to sit in on a presentation I wanted to give, they would have to
: get permission from their manager to charge to some DoD contract their spending
: one hour to listen to me.  In this case, the manager refused to do so, so
: despite having a group of programmers interested in what I could offer for as
: an Ada entrepreneur, I could not even get a chance to make my pitch.
: 	Why did the manager refuse?  As I said before, using my services would
: have allowed them to save the taxpayers and the DoD lot of money on the
: contract, but would have cut into the company's and manager's profits and
: bonuses, under existing defense procurement regulations.  So why bother
: listening to a sales pitch, no matter how relevant.

It is pure speculation on your part as to why the manager did not want to
give permission for you to come in and make your pitch unless you actually
talked to this manager and the manager stated this as the reason.  I know
Rational seldom has any problem with getting time to demo our products and
services.  To the best of my knowlege, we've never been told that we could
not demo our products for the reasons you state.

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

Re: Vendor bashing? Sort of.

[Kent Mitchell]

Michael Feldman (mfeldman@seas.gwu.edu) wrote:
: Of course, it was their business decision to make, and I'm happy they 
: finally reversed it in 1991. 'Course the SEED program, nice as it is,
: is quite difficult to get information about, or rather information is
: available only sporadically, 'cause the person responsible for it keeps
: changing and has tended to give it low priority. 

I think Mike means LEAP here.  SEED is Rational's educational program.

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

Re: Vendor bashing? Sort of.

[Erik Naggum]

[Michael Feldman]

|   So how come investment money is available for these and not for Ada?
|   What are Bertrand Meyer and Adele Goldberg and the M3 folks doing right
|   that we are not doing? Who is backing them?

could it be that they have managed to solve the "demo problem" and have
enticed their sponsors and investors help them take the next step?  my
impression of Ada (and the mandate) is that it tries to take one big step
and ask nobody for help.  a pearl of wisdom very expensive in its
acquisition: if you communicate strongly enough that you don't need help,
you will never get any, even when you need it.

#<Erik>
--
Microsoft is not the answer.  Microsoft is the question.  NO is the answer.

Re: C++ bashing (was Re: Vendor bashing? Sort of.)

[-mlc-+Schilling J.]

In article <35isfn$pqd@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>
>C++ chugged out of AT&T as a preprocessor

Saying this (because the first C++ compilers happened to take advantage
of C as an already existing, portable code generator) is equivalent to 
calling GNAT a preprocessor (because it happens to take advantage of the
gcc back end as an already existing, portable code generator).

In fact, both are true compilers, not preprocessors.  Their choice of
intermediate representations carries with them both benefits and costs, 
as is always true in compiler design.

-- 
Jonathan Schilling
Novell, UNIX Systems Group (UNIX System Laboratories)
jls@summit.novell.com

Re: C++ bashing (was Re: Vendor bashing? Sort of.)

[Robert Dewar]

I would not quite put C-Front in the same category as GNAT. The big difference
is whether you are generating source code as an intermediate step. The
wword preprocessor is normally reserved for translator systems that do
generate intermediate source. In no sense whatever does GNAT generate C,
it links directly to the GCC backend, and by no stretch of the imagination
can GNAT be called a preprocessor (if GNAT is a preprocessor, so are all
the front ends of GCC, including C itself).

Now of course ideally, if the intermediate source code is 100% hidden from
the user, then it is not so important a distinction, however, it can
certainly effect efficiency (there is no efficient way of handling Ada OR
C++ exceptions if you have to generate C source code).

Re: Vendor bashing? Sort of.

[Michael Feldman]

In article <35j1u5$re1@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:

>Yes, well there are two big mistakes that non-business oriented technical
>people make. First, they think that being technically best is a guarantee
>of success, and second, they think that not being technically best is a
>recipe for failure. Mike, there are dozens of companies around that have
>been destroyed by technically oriented management that did not understand
>how relatively unimportant technical superiority ranks on the scale of
>things.

Certainly - did I imply otherwise? My statement was only that Ada's own
_proponents_, in the main, did not act on the potential for Ada as a
dual-use technology. They already _had_ the good thing; they made too
little of it, simply by targeting only (or mainly) government projects.

>Such matters as perceived and actual levels of support, estimation of
>financial soundness of the companies involved, size of the companies
>involved, time to market, etc. etc often play a much larger role.

Is this a commentary on the Ada companies?

>If you think of Modula-2 and Modula-3 as commercial successes which you
>are sad that Ada was not able to emulate, then you really have a peculiar
>view of the market. 

No, all I said is that the proponents of M2 and M3 were never timid
about trying to create enthusiasm (markets, if you will). The jury is
out on M3; we'll see what happens as the GNU M3 front end matures.

Modula-2 is another story - we can engage in lots of speculation here
too, but my own experience leads me to conjecture that M2 never really
caught fire - even in the universities - because Niklaus Wirth never
gave the "market" a chance to stabilize. He published _four_ editions
of his book (the de facto standard) in less than ten years, each version
_slightly_ different from the others. It drove implementers nuts - if
they supported the 2nd edition, while their competitor supported the 3rd,
the 2nd-edition compiler was flamed as "old". 

Scratch the surface of the DOS M2 compilers, and you find real but subtle 
incompatibilities due to different editions of PIM ("Programming in Modula-2").
I gave up on it; so did others. Trying to teach a course on M2 concurrency 
was great fun - all my code was larded up with commented-out sections, to 
be un-commented experimentally dependening on which compiler the student 
had. An ad hoc equivalent of #IFEDFs.

I don;t know if the M2 standard was ever adopted; it hardly matters any more.
And of course Wirth has walked away from it, and has nothing at all to
do with M3, as far as I know.

>Mike, there is an easy experiment you can perform now. See if you can
>get any venture capitalist to put up money to support work on Ada 9X.
>All I can say is good luck if you try this! To be fair, you should inform
>the venture capitalists that you do not expect the mandate to be maintained,
>and they should discount the effect of the mandate in estimating the future
>market potential of Ada. 

Oh, I agree. I think it's really too late. Support for Ada 9X will 
have to be re-built from the grass roots up, starting with GNAT. Ada is
too tainted already to be attractive to non-technical money types, 
whatever the digits attached to its name.

>I am certainly not saying that you can succeed with rubbish products, no
>matter how good other things look (consider IBM's failures with the
>PC Jr and the RT as illustrations of this). Equally, there are cases where
>a product really *does* succeed on technical excellence alone, but they
>are few and far between.

Of course. But Ada has technical excellence _and_ a mandate, and that has
always seemed to me to be a quite good basis for building a market outward
from that "platform". But instead of seeing the mandate as _seeding_
an industry, my opinion remains that our industry saw it as all there was.
When money was easier to get, they did not play up the bigger potential.
They let C++ catch 'em by surprise, out of (pretty much) nowhere.

Let's go back to work; you are entitled to your opinion and Ito mine.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
NOTE NEW PHONE NUMBER.
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------

Was... Air Force shows... Now... Vendor Bashing

[Chris Eveleigh]

In article <85B31DC7912@annwfn.com>, merlin@annwfn.com (Fred McCall) writes:
|> Well, having worked with a number of tools (and currently working with
|> what are probably top-end Ada tools -- at least they cost enough), I
|> have to agree in part with the 'vendor bashers'.  I've found the quality
|> of tools to be lower than comparable ones for other languages, as well
|> as being more expensive.  Compiler messages are cryptic (I expect a lot
|> more informative messages -- if the language is going to be that picky
|> and try to force safe practices, the compilers ought to know a lot more
|> than mine is telling me when an error is found).  Development tools are
|> buggy and/or difficult to use.  *EVERYTHING* requires more in the way of
|> resources (including money).  I consider all of this as fall-out from
|> having a captive audience.  
|> 
   ...Stuff deleted...
|> --
|> "Insisting on perfect safety is for people who don't have the balls to live
|>  in the real world."   -- Mary Shafer, NASA Ames Dryden
|> ---------------------------------------------------------------------------
|> merlin@annwfn.com -- I don't speak for others and they don't speak for me.

My two bits...

I personally have too little experience to speak for or comment on the quality 
and ease of use the various tools available for Ada on the whole, but I can speak 
about our tool, BX/Ada.  BX/Ada is a tool designed for the rapid application 
development (RAD) of Motif user interfaces. It generates Ada code targetted to 
the Ada/Motif bindings.  While I won't claim the tool is bug free, I will say 
that it is not "buggy".  It is also *very* easy to use.

I don't mean for this to be a product pitch, I mean it just to cite a case
in point (no pun intended) to say that the quality and ease of use of BX/Ada is 
identical to the quality and ease of use of Builder Xcessory (which generates 
C and C++). My personal opinion, having seen and played with a lot of different 
Motif RAD tools, is that BX/Ada is one of the best tools available for quickly 
and easily developing quality Motif GUI's whether in Ada, C or C++ and that there 
are no trade-off's involved in "settling" for a substandard tool just because 
it's in an Ada environment.  (Does it cost more?  Yes, but that is due to the 
necessity of having to have Ada bindings to the Motif toolkit, and the additional 
cost is not exorbitant given that, IMHO.)

I've read a lot of the AJPO literature, and Ada has been selected for use on
many different projects, not just in the DoD.  I simply can't believe that 
there aren't excellent tools available for use on these projects.

Going back to what dewar@cs.nyu.edu Robert Dewar wrote:

|> ...there are good Ada tools and bad Ada tools...

To coin a phrase:

If the tool is good, tell a friend; if the tool is bad, tell the vendor.
Hmm, I guess the converse is true, too.  :-)

--Chris Eveleigh, BX/Ada Product Manager

Re: Vendor bashing? Sort of.

[Richard Kenner]

In article <35sc7p$78v@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>No, all I said is that the proponents of M2 and M3 were never timid
>about trying to create enthusiasm (markets, if you will). The jury is
>out on M3; we'll see what happens as the GNU M3 front end matures.

Just FYI: From what I understand the GNU M3 front end currently being
developed is meant as a research tool and should not be viewed in the
same manner as the other GCC front ends (C, C++, Objective-C, GNAT,
Pascal, Chill, and Fortran).

Re: C++ bashing (was Re: Vendor bashing? Sort of.)

[Fred McCall]

In <35nlhb$6u0@gnat.cs.nyu.edu> dewar@cs.nyu.edu Robert Dewar writes:

>
>I would not quite put C-Front in the same category as GNAT. The big difference
>is whether you are generating source code as an intermediate step. The
>wword preprocessor is normally reserved for translator systems that do
>generate intermediate source. In no sense whatever does GNAT generate C,
>it links directly to the GCC backend, and by no stretch of the imagination
>can GNAT be called a preprocessor (if GNAT is a preprocessor, so are all
>the front ends of GCC, including C itself).

Well, that *does* make C a 'preprocessor', since most C compilers can be
made to generate assembly (and the first ones did indeed work this
way).  And if C is a 'preprocessor', then GNAT (and C-Front) must be
PRE-preprocessors!

>
>Now of course ideally, if the intermediate source code is 100% hidden from
>the user, then it is not so important a distinction, however, it can
>certainly effect efficiency (there is no efficient way of handling Ada OR
>C++ exceptions if you have to generate C source code).

Sure there is.  You stuff it into a link library and don't generate code
for anything but the library call (which, I believe, is exactly the way
a number of things are done with C-Front -- which is why it's as
incorrect to call it a 'preprocessor' as it is to call any other
compiler one).



--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
---------------------------------------------------------------------------
merlin@annwfn.com -- I don't speak for others and they don't speak for me.

Re: Vendor bashing? Sort of.

[Michael Feldman]

In article <35svf1$77i@cmcl2.nyu.edu>,
Richard Kenner <kenner@lab.ultra.nyu.edu> wrote:
>In article <35sc7p$78v@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>>No, all I said is that the proponents of M2 and M3 were never timid
>>about trying to create enthusiasm (markets, if you will). The jury is
>>out on M3; we'll see what happens as the GNU M3 front end matures.
>
>Just FYI: From what I understand the GNU M3 front end currently being
>developed is meant as a research tool and should not be viewed in the
>same manner as the other GCC front ends (C, C++, Objective-C, GNAT,
>Pascal, Chill, and Fortran).

Thanks for the info on this. I still think it will be interesting
to watch. Modula-2 can be described with reasonable accuracy as
(functionally) Ada--. Modula-3 is therefore Ada--++. :-)

(No concurrency in it, though, AFAIK.)

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
NOTE NEW PHONE NUMBER.
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------

Re: Vendor bashing? Sort of.

[Michael Feldman]

In article <35ko2u$r12@rational.rational.com>,
Kent Mitchell <kdm@rational.com> wrote:
>Michael Feldman (mfeldman@seas.gwu.edu) wrote:
>: Of course, it was their business decision to make, and I'm happy they 
>: finally reversed it in 1991. 'Course the SEED program, nice as it is,
>: is quite difficult to get information about, or rather information is
>: available only sporadically, 'cause the person responsible for it keeps
>: changing and has tended to give it low priority. 
>
>I think Mike means LEAP here.  SEED is Rational's educational program.

Yes. I'm embarrassed by the blunder. Mea culpa...

I got the right company but the wrong abbreviation - I meant Alsys'
program, not Rational's! Rational's SEED program is newer and Rational
seems to be spreading the word on it better than Alsys has.

As I said in the post quoted above, I think Chair hat here) that Alsys 
should be more proactive in publicizing this program. One of its problems
is that the players at Alsys have changed as the merger with TeleSoft 
has played out. 

I'm hoping that Alsys will get LEAP back into some sort of priority.
I'm also hoping that, as Rational works out its reorganization due to
the merger with Verdix, SEED will keep the priority it has and not
lose momentum because of personnel shuffles.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
NOTE NEW PHONE NUMBER.
"Pork is all that stuff the government gives the other guys."
------------------------------------------------------------------------

M3 Network Objects (Formerly: bashing? Sort of.)

[Anthony Gargaro]

In article <3686g5$48n@felix.seas.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:

|> Thanks for the info on this. I still think it will be interesting
|> to watch. Modula-2 can be described with reasonable accuracy as
|> (functionally) Ada--. Modula-3 is therefore Ada--++. :-)
|> 
|> (No concurrency in it, though, AFAIK.)

However, DEC SRC have completed an implementation for programming distributed
systems in Modula-3 called network objects. The approach is remarkably similar
to the way distributed objects are supported in Ada 94.

Re: Vendor bashing? Sort of.

[Kent Mitchell]

Michael Feldman (mfeldman@seas.gwu.edu) wrote:
: I'm also hoping that, as Rational works out its reorganization due to
: the merger with Verdix, SEED will keep the priority it has and not
: lose momentum because of personnel shuffles.

The Rational SEED program is administered by the Marketing department at
Rational.  This department is basically unchanged in the merging of the
companies so I fully expect the program to be continued and even expanded.
In fact, since the merger we have added a number of product from the VADS
product line.  SEED is alive and growing ;-)

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

Re: C++ bashing (was Re: Vendor bashing? Sort of.)

[-mlc-+Schilling J.]

>>In <35nlhb$6u0@gnat.cs.nyu.edu> dewar@cs.nyu.edu Robert Dewar writes:
>>
>>I would not quite put C-Front in the same category as GNAT. The big difference
>>is whether you are generating source code as an intermediate step. The
>>word preprocessor is normally reserved for translator systems that do
>>generate intermediate source. 

If cfront had only done syntax and semantic checking for C++-only constructs,
and passed C constructs on to the C compiler for checking, then it could
rightfully be called a preprocessor.  But in fact cfront does full checking
for the entire C++ language, and no diagnostics should ever appear from 
the underlying C compiler (except due to glitches in either cfront or the
C compiler).  Thus cfront must be considered a legitimate compiler, as would
any similar translator that compiled Ada through C.  (Of course GNAT is also
a legitimate compiler, I wasn't trying to imply it is a preprocessor!)

See also Stroustrup D&E, Sec. 3.3.1, for a similar defense of what cfront is.

Yes, there are certainly limitations to this approach, especially when it
comes to areas like exception handling and symbolic debugging support. 
But the limitations falls under the category of "tradeoffs in compiler 
architecture", not "this is not a compiler".

-- 
Jonathan Schilling
Novell, UNIX Systems Group (UNIX System Laboratories)
jls@summit.novell.com

Re: C++ bashing (was Re: Vendor bashing? Sort of.)

[Robert Dewar]

Jonothan, if you reread my original post, I never said that C-Front was
not a compiler, I said that it was a preprocessor. These two classes are
certainly *not* mutually exclusive. Actually I don't even think that
compiler and interpretor are mutually exclusive.

Of these three terms, I find preprocessor to be the most precise. To me
it means precisely that you have a processor that takes one source language
and generates another which is then subsequently fed into an existing
compiler for the generated language. How much error checking the PP does
seems quite irrelevant to me (there can be compilers that do no checking
and PP's that do lots of checking). The two important charactersitics of
PP's to watch out for are end-to-end environment issues like debugging,
and inefficiencies that come from trying to map into an intermediate
language that cannot be changed (because it is defined, and the downstream
compiler cannot be modified), and might not in fact be appropriate. These
are not necessary problems, since C is set up to accomodate a preprocessor
of its own in any case, the end-to-end problems are often solved, and for
the initial version of C++ there are no serious inefficiencies that come
from the PP approach.

For either the current version of C++ (notably in the exception area), or
Ada (nested subprograms, subunits, and in particular checked arithmetic),
preprocessing into C is sure to cause significant inefficiencies since
these concepts just do not map efficiently into C. Of course one can
partially, but definitely not fully, mitigate these effects by providing
library routines.

So in short there is nothing inherently bad about the idea of preprocessing.
However, it is important to understand that, unlike C front, GNAT in no
sense generates intermediate C code. The reason that is important is that
if it did, it would have no chance of being really efficient. Since it in
fact does NOT generate C code, and since the backend of GCC can be and is 
being modified to accomodate Ada efficiently, there are no arbitrary
barriers to efficiency in GNAT (it's just a matter of time and effort 
to get rid of known sources of inefficiency).

Note that in a certain sense you could call all GCC compilers preprocessors
since they generate assembly language (a choice that is not necessarily the
most efficient in compile time, but carries no runtime penalty, and greatly
eases portability of the GCC system). However, the two possible penalties
for preprocessors are largely absent. Certainly ASM has on arbitrary
restrictions on what you can do. And in most systems, end to end issues
are well handled (although there are exceptions, GCC depends on an assembler
that can accept debugging information, and this is problematic in some
environments -- which is why, for example, there is still no GDB for OS/2).

Re: C++ bashing (was Re: Vendor bashing? Sort of.)

[-mlc-+Schilling J.]

In article <36s7pv$pqk@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
>Jonothan, if you reread my original post, I never said that C-Front was
>not a compiler, I said that it was a preprocessor.  [...]
>
>I find preprocessor to be the most precise [term]. To me
>it means precisely that you have a processor that takes one source language
>and generates another which is then subsequently fed into an existing
>compiler for the generated language.  [...]

We're in complete agreement other than on what the term "preprocessor" means.
To me, the feeling of the term suggests "a little work before starting the 
main work", which fits into the C/C++ and PL/I model of a general purpose 
language that is augmented with a (comparatively smaller and simpler) macro 
language.  Cfront doesn't fit, since {C++ - C} is a bigger language than C.

But I have no idea what the general accepted meaning of "preprocessor" is....

-- 
Jonathan Schilling
Novell, UNIX Systems Group (UNIX System Laboratories)
jls@summit.novell.com