Access the full text.
Sign up today, get DeepDyve free for 14 days.
References for this paper are not available at this time. We will be adding them shortly, thank you for your patience.
SIGBIO Newsletter page 18 ANY iDiOT CAN WRITE COMPUTER CODE: NIGHT THOUGHTS ON CONTEMPLATING A SiTE VISIT REPORT Barry W. Brown. Ph O. Department of Biomathematics M.D. Anderson Hospital Texas Medical Center Houston. TX 77030 The title relects a sentiment that the author has at times attributed to statisticians. The follow-up is that the statisticians proceed to prove their point. With the advent of cheap microcomputers, the applicability of the remark threatens to expand to include the entire biomedical research community. Numerous articles have b e e n written bemoaning the fact that computer software is expensive and time-consuming to produce, and after production tends to be unreliable and difficult to maintain and enhance. An explanation is that a medium to large scale application requires that thousands of details be properly handled; the handling is specified by one who is incapable of simultaneously dealing with ten details. (Doubters might like to recite backwards a list of ten random digits read once). Because of the mismatch in the scale of the task to be performed and the capacity of the performer, writing good computer code is a very difficulty task requiring education and experience. A great deal of planning should be performed before implementation of even a medium-scale program is begun. As a corollary, any attempt to make the initial production of code cheap will cause the overall cost to skyrocket. position seems to be well accepted in of human endeavor. Can one imagine =er telling an engineering firm that they bridge now and consequently the firm :ease performing load calculations and 31ueprints, and start pouring concrete. Or a patient telling a surgeon that he is sick and doens not want time wasted on diagnostice rather the surgeon should begin t, it is common to tell a programmer that a certain capability is needed imeediately and no time can be wasted on design; please commence with implementation. ~iomedical researchers do not are standards for good code j it done rapidly). If there are =n any idiot can write code. walk a football from one end unoccupied field to the other. To infer from this that a professional _ quarterback possesses no unusual skills is a remarkable act of hubris. Similarly, bemoaning the result when code is written without standards is unfair to the coder and also futile. In s o m e cases, researchers know that standards exist but feel that they can be ignored. The author has frequently held and acted on this view. He is usually astounded when he is consequently burned. However. just often enough to keep temptation alive, time has been saved by short cuts. One attempt to evade the problem of difficulty of software creation is providing the end user with an easy to learn language, usually BASIC. The thought is that the user can provide his own specialized applications. BASIC is easy to learn, and it does work well for applications which can be written in a hundred lines or less. For much larger applications BASIC is pretty well an unmitigated disaster. The reader may object that there are large and excellent applications written in this language. My reply would be that I have seen circus performeres ride bicycles while standing on their heads on the seats; this unusual ability is applauded. But. one running a commercial messenger service employing people on bicycles is unlikely to have this ability high on the list of requirements, and indeed, a proclivity to engage in such exploits on the job would be a highly negative factor. Similarly, the ability ot use the inadequate tools of BASIC to create a fairly large program is a feat of bravado which I applaud. It is not a skill required of serious programmers and indeed a tendency to substitute cleverness for appropriate tools should be strongly discouraged. What Js wrong with BASIC? The only currently accepted paradigm of the programming process is one of successive decomposition of problems. The decomposition allows a few details at a time to be considered. Elementary tools of languages which facilitate the breaking of problems into subproblems are locality of scope of variables and the ability to pass arguments to separately constructed procedures. BASIC lacks both. Consequently, a coding detail anywhere in a BASIC program can have ramifications everywhere, and sub-problems can't be separately tackled. In following articles, we will examine other facets of the rush to implementation and their consequences.
ACM SIGBIO Newsletter – Association for Computing Machinery
Published: Mar 1, 1984
You can share this free article with as many people as you like with the url below! We hope you enjoy this feature!
Read and print from thousands of top scholarly journals.
Already have an account? Log in
Bookmark this article. You can see your Bookmarks on your DeepDyve Library.
To save an article, log in first, or sign up for a DeepDyve account if you don’t already have one.
Copy and paste the desired citation format or use the link below to download a file formatted for EndNote
Access the full text.
Sign up today, get DeepDyve free for 14 days.
All DeepDyve websites use cookies to improve your online experience. They were placed on your computer when you launched this website. You can change your cookie settings through your browser.