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,5cb36983754f64da X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-02-11 02:58:06 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!c03.atl99!news.usenetserver.com!newshosting.com!nx02.iad01.newshosting.com!border1.nntp.ash.giganews.com!border2.nntp.sjc.giganews.com!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.adelphia.com!news.adelphia.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 11 Feb 2004 04:58:05 -0600 From: Jerry Coffin Newsgroups: comp.lang.ada Subject: Re: No call for Ada (was Re: Announcing new scripting/prototyping language) Date: Wed, 11 Feb 2004 04:04:53 -0700 Message-ID: References: <20040206174017.7E84F4C4114@lovelace.ada-france.org> <54759e7e.0402071124.322ea376@posting.google.com> <2460735.u7KiuvdgQP@linux1.krischik.com> <54759e7e.0402081525.50c7adae@posting.google.com> <54759e7e.0402091826.2847e0c@posting.google.com> Organization: TAEUS X-Newsreader: MicroPlanet Gravity v2.50 NNTP-Posting-Host: 68.64.173.106 X-Trace: sv3-a23DZYTSocxvqNLj1vhUMjAkF9M5Zjk3Ev0WYUwOmJKq/u4NjIDuHRCDUknU+2RCTk5qQ7TjdVel987!WJtnrWKd7vzClidaLSJIrMFLvzaqoSNCNQIVUYgqf6HOR+aJLWZ11MEFCSCwE8Oup98LfOsEhjGz!L2DHrCgDgnkhoRFulbVk+oE= X-Complaints-To: abuse@adelphia.com X-DMCA-Complaints-To: abuse@adelphia.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:5426 Date: 2004-02-11T04:04:53-07:00 List-Id: In article , jimmaureenrogers@att.net says... [ ... ] > I think you will find, if you look into hard real-time systems, > that performance is critical. I've looked. It's usually not. For real-time systems, the primary requirement is usually for absolute predictability, NOT for maximum performance. > While it is true that GNAT has > produced relatively slow executables in the past, those same > executables are often 3 to 5 times faster than early Java > programs. I know that current JVMs have improved performance > significantly. I speak of JVMs from around the year 2000. Using Java as a standard of comparison is a tacit admission of a major problem. > Other > Ada compilers produce faster code than GNAT. Sometimes you get > what you pay for. (GNAT is a free compiler in the GNU compiler > chain). The last time I checked, GNAT uses the same back-end as the other GNU compilers, so if it doesn't produce as good of code, it's a strong indication of a performance problem in the language proper. > What kind of performance measures do you use in your problem > domain? C programmers are fond of fast code execution and fast > compilation. C++ programmers have similar performance priorities, > but are willing to sacrifice some compiler speed for the > flexibility of templates. Java programmers frequently prize > speed of coding, with the clever use of the large set of API > libraries available to them. Ada programmers are fond of fast > code and early detection of coding defects. Any statement that attempts to characterize all C++ (or Java or Ada) programmers as having the same priorities as each other is bound to be false. Worse, there's a tendency to overcompensate for perceived weaknesses at the expense of perceived strengths. Thinking of error reporting as a weakness, many C++ programmers frequently put tremendous work into it. Conversely, many C++ programmers take execution speed so much for granted that they write horribly inefficient code on the assumption that the compiler can (and will) make up for whatever they do. Though I don't work with as many Ada programmers on as regular a basis, it appears to me that many do more or less the opposite: it's so widely assumed that the compiler will catch almost all errors, that many blithely assume that almost anything that compiles MUST be correct. At the same time, execution speed has been perceived as a problem often enough that many knowingly and intentionally subvert type-checking and such, on the assumption that it's necessary to get the speed they think they need to be competitive. Without trying to take this too far, the result is that in _many_ cases, what are widely perceived as strengths or weaknesses of particular languages often end up being almost exactly the opposite of what's really the case. In the end, nearly all the factors being discussed depend far more on the programmer than the language, so complacency is common but rarely justified. -- Later, Jerry. The universe is a figment of its own imagination.