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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e52130bf7227ab39,start X-Google-Attributes: gid103376,public From: Jim Hassett Subject: Programming perversities Date: 1996/11/09 Message-ID: <3284A335.1A9A@maroon.tc.umn.edu> X-Deja-AN: 195503379 content-type: text/plain; charset=us-ascii organization: University of Minnesota mime-version: 1.0 reply-to: hassett@acm.org newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (Macintosh; I; PPC) Date: 1996-11-09T00:00:00+00:00 List-Id: Apart from this first paragraph, this message is identical to one I posted to Team Ada the other day (5 Nov). A reader there suggested that this might be of interest to comp.lang.ada readers, so here it is. My apologies to Team Ada readers who have already seen it. The discussion about the NRC report has prompted me to reconsider a puzzle that I have pondered from time to time: Why hasn't Ada become more popular than it is? I've come to suspect that part of the reason is certain "perversities" common among programmers. Of course, this conclusion is based only on inadequate data, anecdotal evidence, and expert judgement, so no one should take it too seriously. About fifteen years ago, I had a disturbing experience while working on a software project. I had just written procedures to implement some new capability, though I no longer recall what that capability was, or even roughly how "big" it was. I did some testing and found that the new procedures appeared to be working flawlessly (must not have been very big). When I saw this, I felt a twinge of disappointment that I would not have anything to debug, immediately followed by revulsion at the thought that I might have been hoping for bugs. The experience taught me something important about myself, and I'm sure it is true for many programmers. I enjoy the intellectual challenge of debugging. There is something about the process that is very rewarding. Uncovering the details of what went wrong, narrowing the scope of the problem, gathering evidence and formulating hypotheses, and finally isolating the flaw are all activities that provide small gratifications throughout the process. I suspect that most programmers are among those people who enjoy mental puzzles of various sorts, and debugging provides the same kind of rewards (as long as one is able to make discernible progress). On the other hand, it seems that few programmers enjoy having a compiler tell them that they've blundered. As a result, I suspect that many programmers find Ada compilers annoying. They would rather discover their "bugs" themselves. Permissive languages let them operate in this mode to a greater degree. I am not claiming that the use of Ada will reliably result in flawless executables, but Ada compilers will reduce the number of errors that are left undetected until run time. Related to these issues is a tendency toward what I call "empirical" programming: figuring out what will work by experimentation, rather than by reading the manuals and working out the logical consequences. Of course, this approach is often necessary due to inadequate specifications (for the language, for the OS, for peripherals, for "legacy" subsystems, or whatever). But even where adequately precise specifications are available, many programmers are more inclined to "try something else" than to dig through the manuals to try to find the real solution to a problem. While this sort of experimentation can be a learning experience, programmers too often settle for the first thing that works, rather than going back to the manuals to understand why it worked. As a result, a hack that works in a few cases that were tested becomes a flaw that results in subsequent problems. What has this got to do with Ada? It makes the precision of the language and the LRM of little interest to many programmers. Also, uninformed experimentation in Ada typically yields the annoyance of compilation errors. Another unfortunate trait of many programmers may be that they take pride in mastering the arcana of programming languages, so the more arcana, the better. Ada programmers may take pride in grasping the subtleties of tasking, or the full power of generics, but Ada has relatively little of the more superficial mysteries of a terse (dare I say unreadable) notation. Such surface arcana make it easier to quickly set oneself apart from the uninitiated, while there will still be many deeper mysteries (or "pitfalls") as well. The language Perl has attained considerable popularity. I regard it as an effective language for small applications, but an abomination in language design. According to the "camel" book (Programming Perl), "the three principle virtues of a programmer are Laziness, Impatience, and Hubris." I assume this is meant to be a bit of humorous hyperbole, but it seems to me a dangerous attitude to encourage. I will admit that laziness may prompt a programmer to seek ways to automate work, that impatience may prompt a concern for efficiency, and that hubris may encourage a programmer to share resulting software with others (often for a fee, of course). But if laziness and impatience lead to sloppy practices, and hubris leads to a stubborn refusal to take the advice of others (including compilers and programming guidelines), it can lead to the sort of unreliable and unmaintainable software that is so common. Another "perverse" characteristic of many people is that they do not like to be told what to do. A certain rebelliousness is no doubt behind much resistance to the DoD Ada policy (or "mandate", if you prefer). By this time, I have no doubt painted a bleak picture of programmers. I have exaggerated. My attitude is not really so negative, but these tendencies seem clear to me. Fortunately, many programmers have other traits that counter these inclinations. I have always thought that meticulousness, precision, and discipline are among the primary virtues of a programmer, and these can go a long way toward balancing laziness and impatience. Finally, I have three disclaimers: 1. If any of the above is someone's opinion, it is only my opinion, as far as I know. 2. The above ramblings are the product of a fevered mind (as I'm at home with the flu today). 3. I have been careful to speak only of programmers. None of the above is meant to apply to software engineers. - Jim Hassett