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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a1ce307c10055549 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-16 05:46:57 PST Path: archiver1.google.com!news1.google.com!sn-xit-03!sn-xit-06!sn-xit-08!supernews.com!newsfeed.news2me.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: IBM Acquires Rational Ada Date: Mon, 16 Dec 2002 08:20:02 -0500 Organization: MindSpring Enterprises Message-ID: References: NNTP-Posting-Host: d1.56.bf.1d X-Server-Date: 16 Dec 2002 13:25:11 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:31888 Date: 2002-12-16T13:25:11+00:00 List-Id: wrote in message news:AB4L9.166662$pN3.10785@sccrnsc03... > > The problem is a "Standard" component library that just plain comes with > > any given Ada compiler by default. > 1) What spec should be implemented for a component. For instance, > a high level abstraction like Claw.Sockets, or a lower level like > Gnat.Sockets? Both? Or are they sufficiently different they don't > compete? The user is back where he started, trying to make a decision. That's a decision I'm willing to defer to some committee that acts as the owner of the library. Granted, its not a simple question. We've watched the debate here over something as relatively simple as a linked list package - everyone wanting something different. There will never be a perfect answer that will satisfy all users, but that doesn't mean that we shouldn't try to come up with something that provides more leverage to the developer. > 2) A compiler vendor must consider not only what would attract new > customers (from his rivals, in a slow growing market), but what keeps > his existing customers from switching. If his current customers are > dependent on his non-standard features/libraries, it would be costly > for them to switch, but standard items make the vendor's product more > a commodity, subject to competition from anyone with a lower price. > For the vendor that's a disincentive to standardization. Microsoft > doesn't offer "standard" components out of good will, they offer > "lock you into Windows" components. Perhaps if there was a monopoly > in Ada compilers, it wouldn't worry about losing customers to other Ada > vendors, but would instead worry about losing them to other languages. I'm well aware of economics. Sure the vendors have a built-in interest in locking customers into proprietary, non-standard answers. Sure, they have to react to what their customers (existing and potential) seem to want and need. But if that were the only issue, then C++ should not have the STL, should it? Or taken a step further, there should be no adherence at all to the ARM or even that there be a "Standard" language called Ada, would there? Obviously, there must be other factors in the industry that cause "standard" libraries to arise for a language because languages seem to have them. There is something to be said for the notion that a rising tide lifts all boats. My argument here is that Ada is at best a bit-part player in the software development play. Changing that helps everyone with an interest in Ada and is going to require truly innovative thinking on the part of those who want to see the language succeed - which I assume includes the vendors. Several years ago, Dodge took a look at the pickup truck market and in the field of large trucks, they owned less than one percent of the US market. They figured that the choices were to either to get out of it or do something radical on the notion that they couldn't reall hurt anything by trying. They conducted lots of research to find out what the potential customer wanted then got really creative and innovative at the drafting table. The result was that they not only dramatically increased their market share but also pretty much forced Ford and Chevrolet to follow their design lead with the result being that the bigger players are now chasing the Dodge, rather than the other way around. Sure its risky and its difficult to see what the right answer is or how to get it done. But lets be realistic. Ada has such a small segment of the software development market that the choices look pretty much the same to me as they did for Dodge. Either milk the cash-cow for as long as you can while it gradually dries up and migrate to some other business, or take some radical action that dramatically changes what Ada means to the whole world. If there were a *will* to do something, I'm sure a way would be found. If the vendors had a strong desire to say "The language should go down this path to make it more valuable..." (Be that a large library, GUI, Database, Operating System, all of the above, or something completely different) then some creative thought could be put into how to get there. Joint funding of some development effort? Government research grants? Volunteer efforts? Combinations of all three? The alternative is to do nothing and continue to watch new development projects go to languages like C++ and Java. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ======================================================================