From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3ccb707f4c91a5f2 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Date: 1996/10/18 Message-ID: X-Deja-AN: 190408653 sender: news@organon.com (news) references: <325BC3B3.41C6@hso.link.com> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-10-18T00:00:00+00:00 List-Id: In article 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