Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!zaphod.mps.ohio-state.edu!ncar!noao!arizona!dave From: dave@cs.arizona.edu (Dave P. Schaumann) Newsgroups: comp.software-eng Subject: Re: Reusability considered harmful??(!!) Message-ID: <867@caslon.cs.arizona.edu> Date: 14 Feb 91 22:43:02 GMT References: <6108@stpstn.UUCP> <87829@tut.cis.ohio-state.edu> <6248@stpstn.UUCP> <1991Feb11.103100.112@skyler.mavd.honeywell.com> <88431@tut.cis.ohio-state.edu> Organization: U of Arizona CS Dept, Tucson Lines: 59 In article <88431@tut.cis.ohio-state.edu> Bruce Weide writes: >In article <1991Feb11.103100.112@skyler.mavd.honeywell.com> >djbailey@skyler.mavd.honeywell.com writes: >> >>A sine routine ought to be a very good candidate for a reusable >>component, but we got bit by a subtle problem. This is one case where >>the algorithm selected was very important and I am interested in how a >>"specification and object code" system would handle it. >> > >Handling this problem (a sine routine that isn't too accurate for some >particular range of values) in a "specification and object code" reuse >scenario is based on the idea that a single abstract concept can have >multiple plug-compatible implementations. [...] Now I see the crux of the reusability issue. What we need is well-defined interfaces between code. The sine function is a good example of this: you pass it a floating point value, and you get a floating point value back. Every language I've seen with sine in it had it defined this way. Naturally, the more polymorphic your language is, the more powerful this idea will be: pass a double (ala C) to the same code in a polymorphic language, and you get a double back. Here, you really don't need to know whether your stack is an array, a linked list, or some other construct. All you need to know is the interface. When you have polymorphism, you don't even need to specify what kind of data elements you have. Thus, I would propose that a necessary feature of any programming environment generating reusable code would provide two features: strictly defined code interfaces, and polymorphic parameters. Naturally, it would be nice to have your language support these features, but you still need the programmer to use the features in a disciplined manner. We already have languages with various combinations of these features: ML, CLU, C++, Ada, etc. What we really need now is to learn how to use these features to enhance the reusability of our code. Not just to understand the concepts involved, but to actually use them in practice. This, I think, points out a major weakness in computer science education (at least in my experience). I've been taught structured programming, object oriented programming, algorithms, analysis, and lots of theory. But what has never really been stressed is the discipline required to be a good programmer. Discipline in style, structure, and planning. Ultimately, I believe that it is the discipline of the programmer, as much as any language feature or advance in theory that makes the difference in how reusable (and modifiable, and debuggable...) the code is. In closing, let me leave you with an example mentioned in this group a few weeks ago. Someone had the odious task of maintaining a program that contained a function consisting ofmore than 1000 lines of code. The original programmer(s) must have thought they were saving something by not abstracting *any* of those 1000 lines, but how can any savings in development time or savings in run time balance the headaches generated by trying to understand such a beast? This is really the essence of discipline: a bit more work now will save volumes of work later. -- Dave Schaumann | DANGER: Access holes may tear easily. Use of the access | holes for lifting or carrying may result in damage to the dave@cs.arizona.edu | carton and subsequent injury to the user.