Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 14-Day Trial for You or Your Team.

Learn More →

Any idiot can write computer code: night thoughts on contemplating a site visit report

Any idiot can write computer code: night thoughts on contemplating a site visit report 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. http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png ACM SIGBIO Newsletter Association for Computing Machinery

Any idiot can write computer code: night thoughts on contemplating a site visit report

ACM SIGBIO Newsletter , Volume 6 (4) – Mar 1, 1984

Loading next page...
 
/lp/association-for-computing-machinery/any-idiot-can-write-computer-code-night-thoughts-on-contemplating-a-SntFn2BumD

References

References for this paper are not available at this time. We will be adding them shortly, thank you for your patience.

Publisher
Association for Computing Machinery
Copyright
Copyright © 1984 by ACM Inc.
ISSN
0163-5697
DOI
10.1145/992237.992248
Publisher site
See Article on Publisher Site

Abstract

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.

Journal

ACM SIGBIO NewsletterAssociation for Computing Machinery

Published: Mar 1, 1984

There are no references for this article.