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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, PLING_QUERY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e0afec3ed133afd9 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Enumerations and Arrays Unnecessary!??? Date: 1997/06/14 Message-ID: #1/1 X-Deja-AN: 248333161 References: <33A16AC0.1BA4@calvin.cca.rockwell.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-06-14T00:00:00+00:00 List-Id: JR Crosmer says <> Whenever a new idea comes along in the software world, it seems to attract a bunch of fanatics who get so enthusiastic about the approach that they decide that using any other technique is completely unacceptable. Some examples are Never write a program without proving it correct Use only referentially pure functional languages Use only systematic top down refinement, no bottom up programming allowed Use only language xxx (and yes I would include Ada, I have been amazed at the past by some fanatics insisting on recoding perfectly good libraries written in other languages). ... And now, use only object oriented design. A good rule is to take ALL advice from such fanatics with a huge grain of salt. What experience shows is that software is complex, and we need all the useful tools and techniques we can find, and we need to learn how to choose the right ones for the right job, and how to make them work together. Sometimes these fanatics give me an image of a salesman who comes along and says "I have this wonderful new plumbing tool, it will do everything, and you can have it free. The only catch is, you have to give me all your other tools, and promise to use only this wonderful new tool from now on." Object oriented design, and associated OOP features in languages are definitely useful. But they are not the only way of doing things, and I often see programs which have been made heavier, less efficient, less maintainable, less readable, and more complex by ludicrous misuse of object oriented approaches. Treating an enumeration literal like Red as an object is almost a characature of such a mistake, and is definitely in the ludicrous category. So, I hope you learned something useful to use in your courses, but whenever you hear these folks telling you NOT to use something that you have found useful, switch to reading comic books till they have finished the sermon :-) As for arrays, there the issue is a little less clear. As a data structure, it is true that arrays are often too low level, and it is useful and appropriate to abstract from the structure. For example, if you look in the GNAT sources, the Node_Id values that are used to identify nodes in the tree are in fact subscripts in an underlying array, but this is not something that is visible or used at the abstraction level. On the other hand, as a storage structure, arrays are fundamental. A language that does not provide arrays at all is severely hampered. There are algorithms which absolutely require random access of the type provided by array references to perform as expected. There have been languages with no arrays, notably original LISP, but in real modern LISP systems you will cerainly find arrays available as a storage structure, although it is not the style to use these extensively at a high level of abstraction. Of course if you are dealing with mathematical concepts involving vectors and arrays, then arrays are the appropriate abstraction, and suggesting otherwise is again ludicrous nonsense (I would not be surprised if the instructor of your course never wrote a serious numerical code -- many programmers have not). Robert Dewar P.S. Oddly enough, although these days I never write numerical code, once I did, since my thesis 30 years ago was in Crystallography, and some of the Fortran code I wrote them is still in wide use :-)