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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-ArrivalTime: 2003-05-01 07:21:50 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: softeng3456@netscape.net (soft-eng) Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc Subject: Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died) Date: 1 May 2003 07:21:49 -0700 Organization: http://groups.google.com/ Message-ID: <9fa75d42.0305010621.55e99deb@posting.google.com> References: <9fa75d42.0304230424.10612b1a@posting.google.com> <9fa75d42.0304240446.493ca906@posting.google.com> <3EA7E0E3.8020407@crs4.it> <9fa75d42.0304240950.45114a39@posting.google.com> <4a885870.0304291909.300765f@posting.google.com> <416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net> NNTP-Posting-Host: 32.97.239.29 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1051798910 8011 127.0.0.1 (1 May 2003 14:21:50 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 1 May 2003 14:21:50 GMT Xref: archiver1.google.com comp.lang.java.advocacy:62979 comp.object:62467 comp.lang.ada:36807 misc.misc:13860 Date: 2003-05-01T14:21:50+00:00 List-Id: "John R. Strohm" wrote in message news:... > "Kaz Kylheku" wrote in message > news:cf333042.0304300835.4800e03e@posting.google.com... > > "John R. Strohm" wrote in message > news:<416273D61ACF7FEF.82C1D1AC17296926.FF0BFD4934A03813@lp.airnews.net>... > > > Apples and oranges, Will. > > > > > > The interesting comparison would be to give both sides the same hardware > > > power, and do the UI software in Ada vs. C. > > > > Newsflash: ``Ada versus C'' is not interesting. Ada and C are much > > more similar than they are different. If you don't think so, it's only > > because you are too absorbed in the arcane details that separate your > > favorite high level assembly language from the next one. > > > > An Ada versus C programming context is the coding equivalent of a > > three-legged race in which each side thinks that their particular > > method of tying legs together gives them an advantage. > > > > Writing UI in either Ada or C is a waste of productivity that could > > only possibly be justified in a freeware project, or some > > tax-dollar-supported researchy thing. (To be clear, I don't mean > > *morally* justified, only economically). > > What such a comparison would yield is a data point on the graph of cost per > function point vs. choice of language. > > There is considerable evidence that strongly suggests that Ada, all by > itself, makes a significant positive difference in programmer productivity > over the embedded software lifecycle, by reducing defect incidence and > promoting earlier defect detection (i.e., compile-time vs. run-time) and > easier debugging and correction (e.g., by a compiler error message vs. a > core dump), when one controls statistically for all other factors. It must > be understood that the embedded software lifecycle is one or two orders of > magnitude longer than the typical commercial lifecycle, and the cost impact > of defects escaping into a fielded project is MUCH higher. (Commercial web > applicatiosn don't kill people when they malfunction. Computer-controlled > radiation therapy machines can, and have. Do a search on "Therac-25".) > > Or is it your belief that cost of software development, and cost of quality, > is immaterial? If so, I recommend you read Phil Crosby's "Quality is Free", > where he advances the concept of cost of quality, by quantifying the cost of > reworking defective material and then showing that the added cost of NOT > generating defective material is generally MUCH lower than the cost of > rework. But you are assuming a stricter type safety translates to higher quality. There is little evidence for that. Type safety is ONE thing that helps quality. But if a little bit of sugar in a recipe is good, ten times the sugar will not make it taste ten times tastier. There are natural limits. Ultimately, type safety only catches relatively minor errors typically made by novice programmers. It cannot catch errors of design and logic, which are the more complex sources of quality defects. Most programmers do not stay novice for their whole careers. (If they do, they should consider other careers too.) So the role of type safety in assuring quality is limited. That having said, if you cannot hire well, a good type safe language might help in eliminating smaller errors. But then, you are never going to have anything working anyway, so what's the big deal about eliminating smaller syntax-level errors? If you can hire well, a super-strong type safe language will only annoy your best programmers, who don't need the type safety to avoid bugs but have to work around it for all the things that they do need to do. You can still deliver projects in that case, but your quality will be poorer, not better, and you will have taken much longer for no good reason. (Though the relation to job-safety issues is apparent, which is why bureaucrat types might love such languages.)