Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation)

[jsa@alexandria (Jon S Anthony)]

In article <dewar.845557517@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> "The funny thing is, no one would be forcing it on them.  This is the
> same sort of goofy situation as occured for pragma Assert.  Hey, a)
> it's optional, b) if you don't want it, don't use it."
> 
> 
> That is a principle often appealed to in the language design process "Hey,
> put in my pet feature, you don't have to use it if you don't need it."
> 
> This is an invalid principle. It is important to remember that every feature

Yes, yes, of course.  But you are pulling one of your Strawman
arguments here.  Sure, in general you can't allow this.  But clearly
it makes sense for those cases which are highly desireable but are
blocked for some rather specific sort of reason attached to a certain
highly vocal (probably) minority view.


> The design team often responded by saying "Show us what is technically wrong
> with a feature, and we will remove it." Well of course that was not the issue
> there was nothng technically wrong with any one feature, it was just the
> aggregate that was a problem. Sort of like being over-budget and insisting
> that you will only remove unjustified items from the budget -- note that
> you can trace many problems with the large deficit spending by governments
> to this problem -- they are over budget, but cannot find individual items
> in the budget that they can happily remove.

I don't see how this particular line of thought is relevant to the
particular case (GC or Assert) in question (especially as you made a
claim in a previous post that Assert would probably end up being in
every Ada95 compiler anyway, just not in a _standard_ way - thereby
giving the worst of all worlds situation).


> convincing to have a single current commercial user of Ada make the
> statement in a way that counts, but in priority wish lists we see
> from such users GC does not figure.

As others have pointed out this plays into the chicken/egg problem.
If there were GC, you may have a lot more (commercial) Ada users.
Market _size_, not market _share_, is the important point.


> Maybe it should, but it is an unconvincing claim to simply state that yu
> are sure that it is the case that adding new feature XXX will increase
> Ada use by YYY without any evidence.

Agreed.  And it is equally unconvincing to claim that not having it
makes no difference since you have no evidence for this.  Actually,
there is at least _some_ evidence (annecdotal for sure) for the claim
that it _would_ make a difference and absolutely _none_ that has been
offered for the other view.


> Note that for every feature not in Ada, there are ardent advocates
> who insist on this being true for their feature. If you listened to
> all of them, you would have far too much junk in the language.

Absolutely, but again, this is just irrelevant for the issue in
question.


> Just as the GC advocates point to Ada, the closure advocate points to ML,
> LISP, SCHEME etc.

Well, there are many differences with the only similarity being, yes
these are two constructs that have been desired.  For one thing, you
can roll your own closure stuff in Ada as it is.  For another, it is
no where near as general purpose an "enabling" construct as GC. For
another,... Really, it is just irrelevant to the question.


> and integers). But there simply aren't enough people.

As I say, you have no evidence for this.  You only have evidence that
there are not enough people currently using GNAT who want GC.


> meanwhile. In the absence of hard data supporting the claim that
> adding feature X will attract existing of new users, you have to
> react to unsupported claims carefully.

Well, fair enough.  But you have to realize that it is also dangerous
(perhaps far more dangerous in the long run) to gamble on this point
of view.


> For an exmaple of a feature that DOES definitely attrct new Ada
> users, consider Annex E (distribution). We are definitely finding
> that this *is* attracting new users to consider Ada 95. This is not
> a guess, it is based on real customers sending us messages telling
> us they are interested!

Well, THAT'S BECAUSE IT'S THERE!!  Come on - you can't even remotely
bring this up as a point here.  The chicken/egg dilemma is resolved.
Suppose it wasn't.  We could just as easily be having this
conversation about DSA.  Actually, it would not be as easy, because
DSA is covered (and more competely) by CORBA based ORBs directly
supporting Ada95.  For myself, while I think DSA is nice, it is just
not that big of a deal when you have the latter floating around all
over the place, offered by several vendors, language neutral, with
hooks into OLE/COM, with a cast of thousands improving it daily, etc.,
etc., etc.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com