Re: Enumerations and Arrays Unnecessary!???

[dewar@merv.cs.nyu.edu (Robert Dewar)]

JR Crosmer says

<<In the past six months I have a course in object oriented design and
another one in object oreinted design (5-days each) .  In each course
the instructor insisted rather stronly that "There is no need for
enumeration types or array types."  Neither instructor had any
familiarity with Ada83 or Ada95.  They each suggested that an
enumeration litteral be thought of as an object: e.g., send a message to
the color Red to do something.  Thay also insisted that in any
situations in which an array is used, the implementation is not a good
fit to the underlying problem.
 
In my experience, I would be very hard pressed to give up either 
enumerations or arrays, especially with the capabilities allowed
and enhanced with Ada attributes and data typing rules.>>


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 :-)