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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10261c,cfbb90c56a313e70 X-Google-Attributes: gid10261c,public X-Google-Thread: 103376,cfbb90c56a313e70 X-Google-Attributes: gid103376,public From: "Pat Rogers" Subject: Re: From extended Pascals to Ada 95 guide Date: 2000/08/25 Message-ID: #1/1 X-Deja-AN: 662468127 References: <8o3s2a$9ph$1@nnrp1.deja.com> <8o4bfq$v0h$1@slb7.atl.mindspring.net> <39A655BE.18E89020@maths.unine.ch> <4Oxp5.428$Ze5.13712@nnrp3.sbc.net> <39A6B3FF.73538A0E@acm.org> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Complaints-To: abuse@swbell.net X-Trace: nnrp2.sbc.net 967229448 208.191.184.67 (Fri, 25 Aug 2000 13:50:48 CDT) Organization: SBC Internet Services X-MSMail-Priority: Normal NNTP-Posting-Date: Fri, 25 Aug 2000 13:50:48 CDT Newsgroups: comp.lang.ada,comp.lang.pascal.misc Date: 2000-08-25T00:00:00+00:00 List-Id: "Marin D. Condic" wrote in message news:39A6B3FF.73538A0E@acm.org... > Pat Rogers wrote: > > Some baggage never gets lost... > > > > This idea that development in Ada is more expensive than in other > > languages must be challenged whenever we come across it. The tool > > costs can be very reasonable and in my experience (and others' as > > well) programmer productivity can be extremely high indeed. > > > I would agree, but with a qualification. In some domains with some > development environments, you get lots of prepackaged, well integrated > services. The language itself (Ada) is going to be faster/better/cheaper > to develop in than (say) C++ or some other popular languages because of > ease of understanding, extensive checking to avoid bugs, easier > debugging, easier configuration management, etc. However, its hard to > compete with something like Microsoft Visual C++ for PC app development > simply because of the body of code leveraged through the MFC and the > really spiffy, well integrated IDE. While similar tools are available > with Ada to some extent, you don't get the whole thing in one nice kit, > so you'll lose time in pulling the tools together, integrating them, > figuring out how to use them, etc. For some domains you may not have > these tools at all. Yes, that's the quentissential example of "All other things being equal" that I had in mind. > Granted, this is not a "language" issue, but more of a "development > environment" issue. Some other language may be faster to develop in > simply because of the availability of the whole environment - not > because of the language itself. > > > All other things being equal, in a contest between highly-skilled Ada > > programmers and highly-skilled C programmers, I'll bet on the Ada > > people to produce the final code faster. > > > I'd bet the same way. There is a strong body of evidence to support > this. But the "All other things being equal" qualification is a big > issue. True, but I work in embedded/real-time systems for the most part (as do you, if memory serves), and my passions run accordingly. One could argue that today's "desktop language" might become tomorrow's "embedded systems language", and then I should care a great deal more! That's happening with C++ now, and will happen with Java eventually. Neither are technologically supportable substitutions for Ada 95, IMHO, but technology doesn't drive the decisions much. We're thinking along the same lines. pat --- Patrick Rogers Consulting and Training in: http://www.classwide.com Deadline Schedulability Analysis progers@classwide.com Software Fault Tolerance (281)648-3165 Real-Time/OO Languages Adam ... does not deserve all the credit; much is due to Eve, the first woman, and Satan, the first consultant. Mark Twain