Gauntlet gathering rust and dust

Gauntlet gathering rust and dust

[dog.ee.lbl.gov!overload.lbl.gov!agate!usenet.ins.cwru.edu!magnus.acs.ohio]

Well, the dust is gathering and the rust is forming on my original
challenge (over 3 weeks old!) to Ada vendors to tell whether they
intend to exhibit at OOPSLA.  I've seen one reply from one vendor
(primarily a _system_ vendor at that) and have seen mention (by Dave?)
of a handful of others.  Now Booch, in _Software_Engineering_with_Ada_
was espousing an object-oriented approach back in the mid-'80's
(and we didn't know he was that old :-).  Have you guys not read
it?  (Or _Software_Components_with_Ada, or _Object_Oriented_Design_
[which used Ada as one of 5 application languages]).

pragma MODE (SARCASM, 0.5);

Or do you just think your products can't make it in the real world?
Or are you trying to keep Ada secret?

pragma MODE (SARCASM, 0.0);

Am I missing something?

Jim Crigler
Martin Marietta isn't very interested in my opinions.

Re: Gauntlet gathering rust and dust

[Tucker Taft]

In article <1993Jul23.011508.9410@iplmail.orl.mmc.com> jcrigler@theopolis.orl.m
mc.com (Jim Crigler) writes:

>Well, the dust is gathering and the rust is forming on my original
>challenge (over 3 weeks old!) to Ada vendors to tell whether they
>intend to exhibit at OOPSLA.  I've seen one reply from one vendor
>(primarily a _system_ vendor at that) and have seen mention (by Dave?)
>of a handful of others.  

It is generally a mistake to use responses in a network bulletin board
as any statistical indication of anything.  There are many people who
simply don't read comp.lang.<relevant-language>.  There are still more
people who find comp.lang.ada in particular a frustrating bulletin
board given its signal-to-noise ratio.  Finally, there are those who
choose to use other forums to announce their intentions.

Now of course us regular readers/contributors to comp.lang.ada presume
that anyone who doesn't read and participate regularly is somewhat out
to lunch, but I think we should be very careful not to thrust our
personal view on the market as a whole.  It would be interesting to
correlate dollars-and-cents success in the marketplace with participation
in comp.lang.ada.  I suspect there is not much of a correlation.

In any case, to answer part of your question, there will be an Ada 9X
booth at OOPSLA '93, and a couple of tutorials.  Frankly, Ada 9X compilers 
are not ready for prime time yet.  Only RR has released a beta version
of a compiler that does any significant semantic processing of Ada 9X features.
GNAT has full Ada 9X parsing, but little or no Ada 9X semantics yet.
That may change by September, but we are still probably six months away
from having something someone could reasonably call an Ada 9X compiler.
Given a limited budget, one has to weigh spending time and energy on
this year's OOPSLA, versus making a bigger splash next year.  Particularly
at conferences, vaporware is frowned on.  People like to see running
demos, and be able to sign up for immediate delivery (or even better,
get a demo disk to take home).  We just aren't there yet with Ada 9X compilers.

You are right that much of the work on Object-Oriented Design began
with Ada 83, but these days, it is clear that the people going to
OOPSLA are interested in object-oriented *programming*, not just
object-oriented design.  Although I agree that Ada vendors in general
tend to limit themselves too much to the captive Ada market, I would
not see OOPSLA as the best investment for their money this year.

It is not even clear that conferences at all are a good investment
for compiler vendors.  Compilers are fundamentally boring things to look at;
and exhibition booths and space are expensive.  One should not
evaluate companies on whether or not they attend certain conferences
or advertise in certain magazines.  The question is how much product
they ship, of what quality, and with what profit margins.  
Marketing is far from being a science, and just because a company 
doesn't advertise in a channel that is important to a reader 
of comp.lang.ada, doesn't necessarily determine whether they are 
reaching the relevant potential customers.  

>Jim Crigler

S. Tucker Taft    stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138

Re: Gauntlet gathering rust and dust

[sdd.hp.com!vixen.cso.uiuc.edu!uchinews!news]

  [Since I had this marked for some unknown reason, why not: Sarcasm mode on]

In article <1993Jul23.011508.9410@iplmail.orl.mmc.com> jcrigler@theopolis.orl.m
mc.com (Jim Crigler) writes:
>...
>of a handful of others.  Now Booch, in _Software_Engineering_with_Ada_
>was espousing an object-oriented approach back in the mid-'80's
>(and we didn't know he was that old :-).  Have you guys not read
>it?  (Or _Software_Components_with_Ada, or _Object_Oriented_Design_
>[which used Ada as one of 5 application languages]).

I read all of these a long time ago; great for Ada and Modula programming
(with ADT's and later OO).

>...
>pragma MODE (SARCASM, 0.5);
>
>Or do you just think your products can't make it in the real world?
>Or are you trying to keep Ada secret?
>
>pragma MODE (SARCASM, 0.0);
>
>Am I missing something?

pragma MODE (SARCASM, 0.5);

While Ada may just now be gaining some respect, it did have generics
(templates), exception handling (sound familiar?), packaging (still missing
in many languages), and even tasking (for concurrent programming) back in
the early 80's, back before OO had such constructs.  Since these facilities
are just now becomming available in mainstream OO, one could say being ahead
of its time was Ada's biggest problem (in some respects, anyway).

And now that Ada is adding class-wide types, which provide the kind of
polyorphism and message passing I've advocated (for some time) as preferable
to downcasting and typecases, its actually leaving some of the statically
typed OO languages behind (are the ANSI committees for these languages
listening?-)

If your favorite language (just what is that anyway, Jim) is missing any
of the aforementioned capabilities, why pick on Ada?  And on keeping Ada
secret, Ada's use is mandated by the government and military because of its
emphasis on reliable, large-scale software development, a lot of which is
classified.  That's why many of the published statistics on programming
language usage seem cockeyed to me, they obviously have a low content
validity, meaning they aren't necessarily representative of what's actually
being used.

pragma MODE (SARCASM, 0.0);

bob

Re: Gauntlet gathering rust and dust

[agate!howland.reston.ans.net!usc!sdd.hp.com!col.hp.com!csn!news.den.mmc.c]

Bob Hathaway (rjh@geodesic.com) wrote in response to some semi-sarcastic
comments of mine:

: If your favorite language (just what is that anyway, Jim)

Actually, I don't _have_ a favorite; I'm like a language wino:  I
program in whateversaround.  At work, I'm constrained to FORTRAN and C;
at home, C, Forth, BASIC; at grad. school, I've been working with Ada
for some time.  (In fairness to my employer, I have, in previous
assignments worked extensively with Ada {several KLOC}, less with PL/M
and HP's Rocky Mountain Spotted BASIC.)

: If your favorite language [...] lacks of the aforementioned
: capabilities, why pick on Ada?

I didn't intend to pick on Ada (which I like!); my intention was to
pick on Ada _vendors_ for their ignoring the commercial industry.

: And on keeping Ada secret, Ada's use is mandated by the government
: and military because of its emphasis on reliable, large-scale
: software development, a lot of which is classified.  That's why many
: of the published statistics on programming language usage seem
: cockeyed to me, they obviously have a low content validity, meaning
: they aren't necessarily representative of what's actually being
: used.
 
Agreed that published stats seem cockeyed (listening, Greg?  Keep
listening...), but what % is classified?  (That statistic is probably
classified, too :-) But I have a feeling that it's probably < 25%.
Anybody got real numbers?

Jim Crigler
---------------------------------------------------------------------
Opinions only.

Re: Gauntlet gathering rust and dust

[Gregory Aharonian]

>Agreed that published stats seem cockeyed (listening, Greg?  Keep
>listening...), but what % is classified?  (That statistic is probably
>classified, too :-) But I have a feeling that it's probably < 25%.
>Anybody got real numbers?
>
>Jim Crigler

Of course I am listenting, Jim.  The question is, is Emmett Paige
(overall head of Ada), Lloyd Mosemann (frontman for Ada policies),
John Foreman (head of Ada STARS), and Christine Anderson (head of Ada9X)
listening?  I have no idea why these people are afraid to do an honest
study of what is actually going on inside and outside the DoD with
regards to programming language use, other than maybe embarassment on
a massive scale for the DoD.

One point though, the larger the amount of classified Ada use, the
lower the non-defense programming language gross domestic product for
Ada will be (even lower than my current guess of 2%).  So the more Ada
is actually used inside the DoD, the worse will be its track record
outside the Mandated world.  So this line of arguing actually hurts Ada.

Everyone in the Ada world desparately needs a programming language census
as I have outlined repeatedly.  That no one is willing to fund such a
study is the best measure of Ada apathy and hypocrisy.  The DoD doesn't
fight military wars in the blind - why is it fighting a software war so?

-- 
**************************************************************************
 Greg Aharonian
 Source Translation & Optimization
 P.O. Box 404, Belmont, MA 02178

Re: Gauntlet gathering rust and dust

[Charles H. Sampson]

In article <SRCTRAN.93Jul27201723@world.std.com> srctran@world.std.com (Gregory
 Aharonian) writes:
>
>One point though, the larger the amount of classified Ada use, the
>lower the non-defense programming language gross domestic product for
>Ada will be (even lower than my current guess of 2%).  So the more Ada
>is actually used inside the DoD, the worse will be its track record
>outside the Mandated world.  So this line of arguing actually hurts Ada.

     Excuse me?  This is an argument that I haven't seen before and I don't
follow it.  Could you explain how the classified use of Ada will hurt Ada
for non-defense projects?

				Charlie

Re: Gauntlet gathering rust and dust

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!darwin.s]

In article <1993Jul27.184346.24663@iplmail.orl.mmc.com> jcrigler@theopolis.orl.
mmc.com (Jim Crigler) writes:
> 
>Agreed that published stats seem cockeyed (listening, Greg?  Keep
>listening...), but what % is classified?  (That statistic is probably
>classified, too :-) But I have a feeling that it's probably < 25%.
>Anybody got real numbers?

Although classified projects probably do contribute something, the mix
of languages used in such projects is probably about the same as that
used in non-classified DoD work.  It amy even be argued that it is
easier, and therefore more likely, to violate the mandate in a
classified environment.

What REALLY skews the numbers is that nobody is counting.  The vast
majority of the 'statistics' are just estimates.  

"What is your source for that revelation?", he asked.

In over thirty years of software and system engineering for the DoD,
involving work on projects totalling several millions of lines of code,
I have never, repeat NEVER, been associated with a contract which
required that we report Lines of Code.  We have been asked, not
required, to provide estimates, wild-assed-guesses, source-listing-
page-counts with an estimate of LOC/page, person-months with an estimate
of LOC/person-month, even a count of the line-feeds in the source files,
but NEVER have we been asked to provide a certifiable count of LOC
against an official definition of a LOC.

I am sure that there are many contracts which DO require such reporting,
but my experience indicates that there are many which do not.  Given the
absence of data, how can one draw ANY conclusions?

Of course, finding out anything useful about the size of commercial
software must be just as difficult. :-)

--
Laurence L. Van Dolsen - Der fliegender Hollander
My opinions are my own, but you are welcome to them.
Paramax - (805) 987-9302 - vandolsen@cam.paramax.com

Re: Gauntlet gathering rust and dust

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!uwm.edu!]

>From article <1993Jul28.175352.36592@source.asset.com>, by vand@source.asset.c
om (Laurence VanDolsen):
> In article <1993Jul27.184346.24663@iplmail.orl.mmc.com> jcrigler@theopolis.or
l.mmc.com (Jim Crigler) writes:
>> 
>>Agreed that published stats seem cockeyed (listening, Greg?  Keep
>>listening...), but what % is classified?  (That statistic is probably
>>classified, too :-) But I have a feeling that it's probably < 25%.
>>Anybody got real numbers?
> 
> Although classified projects probably do contribute something, the mix
> of languages used in such projects is probably about the same as that
> used in non-classified DoD work.  It amy even be argued that it is
> easier, and therefore more likely, to violate the mandate in a
> classified environment.
> 
> What REALLY skews the numbers is that nobody is counting.  The vast
> majority of the 'statistics' are just estimates.  
> 
> "What is your source for that revelation?", he asked.
>

I think it will (would) be quite difficult to come up with repeatable 
numbers across a wide variety of programs (projects).  I could turn 
this into a Software Metrics discussion, but I'm going to resist that
temptation :^).  I will repeat a question I've asked before: 

	Who cares about the raw numbers? 

It doesn't really matter how many LOC are written in language X or how
many software houses use language Y (names obscured to protect the guilty)
What matters is "Which language is being used to solve the problems of
emerging technologies?".  Another important question that presumes an 
answer to that one is "How well is it doing it?".

It will always be the case that the older languages will predominate any
"body of use" study.  The idea is for programmers to stay ahead of the 
game by learning the emerging paradyms (emphasis here) ****before****
they emerge.  Running to jump on the current fad's bandwagon isn't going
to get you very far.

Here's a hint:

	Concentrate on the flaws in the current fad.


-- 
Dave Willett          AT&T Federal Systems Advanced Technologies
If you want to know --- ASK!  -- Linda Ellerbee

Re: Gauntlet gathering rust and dust

[Gregory Aharonian]

>>
>>One point though, the larger the amount of classified Ada use, the
>>lower the non-defense programming language gross domestic product for
>>Ada will be (even lower than my current guess of 2%).  So the more Ada
>>is actually used inside the DoD, the worse will be its track record
>>outside the Mandated world.  So this line of arguing actually hurts Ada.

>     Excuse me?  This is an argument that I haven't seen before and I don't
>follow it.  Could you explain how the classified use of Ada will hurt Ada
>for non-defense projects?

Classified use of Ada does not hurt potential use of Ada for non-defense
projects (and in fact would help), but it does hurt statistics of Ada use
in the non-defense world, at least according to the way I calculate such
things.

For example, I recently counted 125 C/C++ jobs in the Boston Globe help
wanted ads, and 5 Ada jobs, for a ratio of 25:1 (a ratio that has
been at this level for years).  Now assume half of all Ada jobs are actually
DoD related.  That means that the ratio for Ada use in the non-defense
world gets "worse", to 50:1.  You now tell me that Ada is used for a lot
of classified projects I don't know about, but for which some Boston area
companies will be hiring.  This makes the ratio even worse.  (Of course,
my ratios have to be adjusted for that great national, top top secret, the
percent use of C/C++ in classified DoD projects).

    So the more classified Ada work going on, the worse the interpretation
is of the dismal demographic statistics I have been collecting on Ada are.
So when the original person critique me for ignoring the impact of classified
Ada projects, my response was that it cuts both ways.

    Though for the most part, this is a argument mostly for statisticians.
-- 
**************************************************************************
 Greg Aharonian
 Source Translation & Optimization
 P.O. Box 404, Belmont, MA 02178

Re: Gauntlet gathering rust and dust

[Marcus J. Ranum]

stt@spock.camb.inmet.com (Tucker Taft) writes:
>It is generally a mistake to use responses in a network bulletin board
>as any statistical indication of anything.  There are many people who
>simply don't read comp.lang.<relevant-language>. [...other reasons...]

	The best reason not to take responses on USENET as statistical
indicators of anything is because they're a self-selected sample. Such
samples have virtually no statistical relevance, because they often
amount to polling the choir. For example, what is the statistical
validity of a self-selected sample of the NRA's voting membership,
polled on their feelings about gun control? (both NRA and HCI play
this game, but mostly as a fund-raiser: "Surprisingly, 95% of our
membership agreed with our basic organizational purpose!!!")

	More often, they're skewed because the only folks who respond
are the folks who feel strongly about the issue in the first place. This
is basic stats 101 stuff.

mjr.

Re: Gauntlet gathering rust and dust

[agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!]

Tucker Taft (stt@spock.camb.inmet.com) replied to my lament over the
lack of replies to my original(original) posting about Ada vendors and
OOPSLA:

: It is generally a mistake to use responses in a network bulletin board
: as any statistical indication of anything.  There are many people who
: simply don't read comp.lang.<relevant-language>.  There are still more
: people who find comp.lang.ada in particular a frustrating bulletin
: board given its signal-to-noise ratio.  Finally, there are those who
: choose to use other forums to announce their intentions.

Point well taken.  After my complaining of Greg's not using real
statistics, here I am doing the same thing!  But I have the same
problem Greg has (though on a much smaller scale):  Are there any
real statistics to be had.

: Now of course us regular readers/contributors to comp.lang.ada presume
: that anyone who doesn't read and participate regularly is somewhat out
: to lunch, but I think we should be very careful not to thrust our
: personal view on the market as a whole.  It would be interesting to
: correlate dollars-and-cents success in the marketplace with participation
: in comp.lang.ada.  I suspect there is not much of a correlation.

Thanks for the perspective.  Agreed on both points.

: In any case, to answer part of your question, there will be an Ada 9X
: booth at OOPSLA '93, and a couple of tutorials.
[compiler status stuff deleted]

GOOD!

: You are right that much of the work on Object-Oriented Design began
: with Ada 83, but these days, it is clear that the people going to
: OOPSLA are interested in object-oriented *programming*, not just
: object-oriented design.  Although I agree that Ada vendors in general
: tend to limit themselves too much to the captive Ada market, I would
: not see OOPSLA as the best investment for their money this year.

Possibly true, which makes me that much happier that 9X the language will
have some presence.  Can you provide more details?  (My employer ...)

I read about the tutorials (cf original(original post))

: It is not even clear that conferences at all are a good investment
: for compiler vendors.  Compilers are fundamentally boring things to look at;
: and exhibition booths and space are expensive.
[stuff about marketing deleted]

But Alsys (at least) has (or had) a `free' all day product showcase
that goes from city to city (or, at least from defence city to defense
city) -- I've been to one.  So the materials and presentation are
already ready.

Jim Crigler jcrigler@polaris.orl.mmc.com
            crigler@longwood.cs.ucf.edu
            jc8715@olympus.ir-unix.ucf.edu
----------------------------------------------------------------
Axiom 2:      a. Perspective is 90% of everything.
              b. Communication is the other half.
Corollary 1:  There exist non-orthogonal dimensions.