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-Thread: 103376,aea4cc77526f5e4a X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newshub.sdsu.edu!newscon04.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!newssvr21.news.prodigy.net.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada References: <7xJvj.7420$Ru4.4246@newssvr19.news.prodigy.net> <1wkwj.10399$0o7.2971@newssvr13.news.prodigy.net> Subject: Re: Separate Compilation in Programming Languages X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-ID: NNTP-Posting-Host: 70.134.112.39 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr21.news.prodigy.net 1204304738 ST000 70.134.112.39 (Fri, 29 Feb 2008 12:05:38 EST) NNTP-Posting-Date: Fri, 29 Feb 2008 12:05:38 EST Organization: SBC http://yahoo.sbc.com X-UserInfo1: O@Y[R^[GZRRER_H]]RKB_UDAZZ\DPCPDLXUNNHLHQAVTUZ]CLNTCPFK[WDXDHV[K^FCGJCJLPF_D_NCC@FUG^Q\DINVAXSLIFXYJSSCCALP@PB@\OS@BITWAH\CQZKJMMD^SJA^NXA\GVLSRBD^M_NW_F[YLVTWIGAXAQBOATKBBQRXECDFDMQ\DZFUE@\JM Date: Fri, 29 Feb 2008 17:05:38 GMT Xref: g2news1.google.com comp.lang.ada:20151 Date: 2008-02-29T17:05:38+00:00 List-Id: "Ray Blaak" wrote in message news:ud4qgnvqt.fsf@STRIPCAPStelus.net... > > In the interests of keeping any controversy alive, if you accept the use of > tools that help an Ada compiler know what to rebuild based on what source > files have changed, how is the use of tools that help a Java compiler to do > the same thing a sign of deficient dependency control? I.e. Ant. > Tools are fine. Every programming language benefits from tools. As I noted in another post, there is no perfect programming language. However, the problems of Java are inherent in the language design. While we all know that C++ is a language that is error-prone, that is not what we would expected of Java. On the other hand, Ada is a more consistent design that does not have as many design flaws as Java, and certainly not nearly as many as C++. In the case of C++, the tools have never been enough. For Java, it turns out, the tools are also insufficient for ensuring that language-based problems are elmininated from an application design, especially when that application is a large-scale software system. My concern is the dependability of software systems embedded in the tools and weapons used by our military personnel. They go into battle, placing their lives on the line using the software tools we provide. I long ago realized that any decision to use C++ for these kinds of systems was irresponsible (unless C++ was reigned-in drastically, as it is on JSF). I did not, until recently, worry as much about Java. Now, with my recent investigation of Java, I have concluded that it is also fraught with problems that can (and apparently do) produce errors in software that are difficult to trace and even more difficult to predict. The more I examine the evidence about Java, the more I realize it is not dependable enough for the kind of systems where people's lives are at stake. Therefore, I will, as noted earlier, recommend against the use of Java for military systems where dependability is an issue, whenever I can. When we are required to apply engineering practices in the development of computer software, neither C++ nor Java are sufficiently well-designed to measure-up to a rigorous model of engineering. Ada also falls short in some respects, but is not as bad as the alternatives. SPARK certainly comes closer to satisfying engineering principles and practices. As of this moment, there is no language that satisfies engineering as well as we might like. But that does not justify using languages that are so flawed that an engineer cannot depend on them to actually behave in predictable ways. Richard Riehle