petcher@skvax2.csc.ti.com (02/28/89)
> Something that neither one of you guys addressed, and that I think is > crucial to the whole "Top-Down Design" issue, is reusability. > Top-down design implies leaves that are custom made for the program > at hand. Reusability implies molding the problem definition around > leaf (and maybe not-so-leaf) modules that are already available. > After all, for a hardware design, you wouldn't design your own ICs, > would you? Top-down design need not be incompatible with re-usability. The key is to do only the design in a top-down fasion, followed by bottom-up implementation. Malcolm Petcher
rjh@cs.purdue.EDU (Bob Hathaway) (03/03/89)
In article <8902281333.AA26629@ti.com> petcher@skvax2.csc.ti.com writes: >> Something that neither one of you guys addressed, and that I think is >> crucial to the whole "Top-Down Design" issue, is reusability. >> Top-down design implies leaves that are custom made for the program >> at hand. Reusability implies molding the problem definition around >> leaf (and maybe not-so-leaf) modules that are already available. >> After all, for a hardware design, you wouldn't design your own ICs, >> would you? > >Top-down design need not be incompatible with re-usability. The key is to do >only the design in a top-down fasion, followed by bottom-up implementation. > >Malcolm Petcher I agree, keeping reusability in mind while designing any software will result in reusable parts. The only reason to "custom make" software is for efficiency so the tradeoff is clear. With inline pragmas the benefit of procedural abstraction can be realized without cost but since violations of abstraction boundaries is not permisable to the programmer, some optimizations cannot occur. But I think the benefits of well designed software outweigh their cost. Profiling software looking for bottlenecks can point out good optimization points, if any. Bob Hathaway rjh@purdue.edu