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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Date: 1996/10/17 Message-ID: X-Deja-AN: 190111868 references: <325BC3B3.41C6@hso.link.com> organization: New York University newsgroups: comp.lang.ada Date: 1996-10-17T00:00:00+00:00 List-Id: Jon said "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 you add to a language damages it by adding to the complexity, and also possibly by adding to the difficulty of implementation, which can damage the quality and availability of implementations. Note that this applies even to optional features, since any implementation effort will at least need to take into account the possibility of implementing the feature in the future, and very often one ends up implementing things that no one will use (how many people have used all the features in the informatoin systems annex yet?) So the question to ask is whether the increase in functionality compensates for the damage being done by adding the new feature. During the Ada 9X design process, the design team proposed MANY features that you do not see today. For the feature enthusiasts, see mapping documents one and two for some interesting archeology. The nearly unanimous reaction of WG9 and the DR's was that the language as proposed was too big and too complex. 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. It's interesting in this thread that we essentially see a replay of many of these discussions. What you have is a couple of people posting over and over again saying that (a) they want feature x and (b) they are sure that feature x would mean that many more people would use Ada. It would be more 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. 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. 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. For example, someone, I forget who, pops up and argues that the single fatal error in Ada is the failure to provide full first class functions (with full closures -- please don't confuse this with the downward closure argument that has raged from time to time on CLA). Just as the GC advocates point to Ada, the closure advocate points to ML, LISP, SCHEME etc. ----------------------------------^ should be Java of course I happen to agree that GC is an important feature, though I still have some reservations about including it in a language of the semantic level of Ada (which permits things like unchecked conversions between pointers and integers). But there simply aren't enough people. Some people complain about the community being inbred, but as in the theater world, the most important thing is to worry about your current audience. There is nothing more fatal than to go off on fantasy trips after new audiences, and lose your current audience 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. 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! As I have said a few times, I think the most valuable contribution of Java may be to heighten people's awareness of the value of garbage collection. But I trust it should be clear to people that the success of Java is not because it has garbage collection, in fact I look to exactly the opposite effect, the success of Java will RESULT in more interest in GC.