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: 101deb,3488d9e5d292649f X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,e6a2e4a4c0d7d8a6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-21 13:46:38 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.berkeley.edu!news-hog.berkeley.edu!ucberkeley!nntp-relay.ihug.net!ihug.co.nz!west.cox.net!cox.net!p01!news1.west.cox.net.POSTED!53ab2750!not-for-mail Message-ID: <3E569E8C.4050709@cox.net> From: "Donald L. Dobbs" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.pl1,comp.lang.ada Subject: Re: status of PL/I as a viable language References: <3E51908E.9CCA3412@adaworks.com> <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net> <3E51ABCE.5491B9A2@adaworks.com> <3E5273DE.2050206@cox.net> <3E531E6F.BDFB2599@adaworks.com> <3E546C45.4010406@cox.net> <3E54F926.441D5BB5@adaworks.com> <1045763933.848350@master.nyc.kbcfp.com> <42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net> <1045769690.126389@master.nyc.kbcfp.com> <1045839419.823502@master.nyc.kbcfp.com> <3E568EF3.A244212A@adaworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 21 Feb 2003 21:46:32 GMT NNTP-Posting-Host: 68.4.138.157 X-Complaints-To: abuse@cox.net X-Trace: news1.west.cox.net 1045863992 68.4.138.157 (Fri, 21 Feb 2003 16:46:32 EST) NNTP-Posting-Date: Fri, 21 Feb 2003 16:46:32 EST Organization: Cox Communications Xref: archiver1.google.com comp.lang.pl1:4409 comp.lang.ada:34397 Date: 2003-02-21T21:46:32+00:00 List-Id: Richard Riehle wrote: > Hyman Rosen wrote: > > >>Dmitry A. Kazakov wrote: >> >>>Should it mean that an unability to create a perfect code (a thing I >>>never saw) in one language excuses any design fault of another? >> >>Nope. I'm just objecting to "If it broke, and it's C++, it's the >>language's fault. If it broke, and it's Ada, it's the programmer's >>fault." > > > Good point. We need to understand that there are limits to what > can be accomplished by depending only on our tools. Ada has > a lot to recommend it for high-integrity software. Other languages > have a lot to recommend them. This started as a PL/I thread, and > I have learned, more recently, of improvements in PL/I since I > last used it. Even so, PL/I, for all its improvements, requires > skilled programmers. Ada requires skilled programmers. C++ > requires skilled programmers. > > My personal preference, based on my experience and current > knowledge of competing languages continues to be Ada, for > the kind of software (such as F-22) we have been discussing. > However, I realize that a highly skilled C++ programmer, one > who understands the built-in pitfalls of the language, and one > who understands how to use smart-pointers, smart arrays, and > lots of other useful C++ classes, can create reliable software. > The same is probably true of a PL/I programmer, but I am not > aware of PL/I being used for many safety-critical applications. > Someone can help me on that, I suppose. > > The key to successful safety-critical software remains, good > engineering. Most programmers have no engineering education, > and all too often, they have insufficient mathematics. On systems > such as the F-22, it is critical that the developers are engineering > aware, and that they have strong mathematics. > > Yesterday, I particiapted in a discussion of requirements specifications > where some of the participants thought it was enough to simply specify > the mathematics needed for the application. The mathematics happened > to involve relatively simple calculus. The eventual design of the > algorithm was expected to be the job of the programmer. Of course, > there would checking, inspection, and testing at some stage, but my > point was that the algorithm should be specified in more detail and > not left to the programmer. > > As long as we ignore the importance of engineering when developing > safety-critical software, we are going to continue to make a mess of it, > and no programming language will save us. > > Ada is like using a torque wrench. C++ is like using any convenient > long-handled wrench. If the mechanic is careful and has a lot of > experience, using that long-handled wrench, it will work just fine. In > most cases, though, we might find the toque wrench a little more > reliable. However, if we have no clue about the appropriate level > of torque, cannot before-hand do the required computations, and > have no idea what torque is, we are going to twist off the head of > the bolt just as easily as the guy with the simple long-handled wrench. > > Richard Riehle > Richard, you have touched on a subject (actually pet peeve of mine for many years in this industry) that I will elaborate on, now. When I first got into the computing business (circa 1962 -- oh my, that probably makes me older than David Frank) we had systems analysts and programmers. The latter were actually "coders". The systems analysts were subject matter experts for the application being contemplated. If it was an accounting or payroll package the S.A. was either a CPA or someone who had a strong background in accounting/bookkeeping, etc. If it was a guidance program for a missile the S.A. was probably a Ph.D. in math or celestial mechanics. The programmer (coder) only had to know his Cobol, Fortran, PL/I or assembly language. He didn't have to know the subject matter of the application to any great degree because the S.A. wrote an air-tight spec that the coder was to rigorously implement. His was not to reason why. We developed pretty good software in those days. Somewhere along the way, it all fell apart when we (as an economy measure in smaller shops, I suppose) invented the Programmer-Analyst. This, IMHO, is the worst single act that has occurred in this industry because we now expect the PA to be both subject matter expect and programmer/coder expert at the same time. The trade journals and web sites are replete with help wanted ads always demanding an individual who is a brain surgeon with ten years of Java, etc. (I exaggerate the point but not by much in many cases.) I suspect that big aerospace projects require so many bodies that there is still some division of labor, but in the commercial world this just isn't sufficiently the case. Dual experts are a rare commodity and even when you find them they have a self-contained conflict of interest because the quality of the Analyst functions will be compromised by the Coder subconscious telling himself that the requirement is too hard to implement or should be implemented in a different way which diminishes the original requirements. I suspect these opinions will instigate a whole new discussion, which I welcome because I think we've all been victim of this phenomenon, directly or indirectly.