Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!sdd.hp.com!decwrl!nsc!pyramid!athertn!paul From: paul@athertn.Atherton.COM (Paul Sander) Newsgroups: comp.sw.components Subject: Re: What is a reusable software component? Message-ID: <28772@athertn.Atherton.COM> Date: 15 Aug 90 04:21:26 GMT References: <27705@athertn.Atherton.COM> <533@helios.prosys.se> <27914@athertn.Atherton.COM> <6729.26c481cb@vax1.tcd.ie> Reply-To: paul@Atherton.COM (Paul Sander) Organization: Atherton Technology, Sunnyvale, CA Lines: 92 In article <6729.26c481cb@vax1.tcd.ie> rwallace@vax1.tcd.ie writes: >In article <27914@athertn.Atherton.COM>, paul@athertn.Atherton.COM (Paul Sander) writes: >>> These should be some way to store the B-tree on secondary memory, so >>> that the data it contains could be reused in another program. >> >> There are a number of features missing from this implementation that could >> be useful. These include Anders' secondary storage capability (which is >> what B-trees are used most for), perhaps with multi user locking. An >> implementation that uses shared memory, again with multi-user >> locking might be useful. Still another that is implemented as a server >> that could allow data to be shared across machines would be useful. > >As a matter of fact I think the module already has too much functionality. These additional features need not be added to this particular implementation. Most of the new features in fact cannot be implemented with same the interfaces as the example. Here, the programmer would have to choose the implementation that best suits their needs. > The >main reason I don't reuse software components (and I program in C++ which >combines the advantages of being the best OOP/software engineering language >around with the vast range of available C code) is that people who write >generic modules put in everything expect the kitchen sink. It is true that many such components include many features, more than most clients need. There is a utility/size trade-off made. However, if the component is carefully designed, and the development environment is decent, the size impact can be minimized; the linker and librarian would omit the unused code from the executable image. > At the moment I'm >working on a project which requires screen handling, file handling via indexes, >and file and in-memory sort functions. There are commercially available >packages available to do all these things. I ignored them and wrote my own for >two reasons: > >1. The commercial packages contained orders of magnitude more code than I need >for this project (a fourth-generation language for writing accounting >software). Their use would have expanded the size of applications produced with >the 4GL from around 100K to an estimated 400K (!!!). > >2. To wade through all the junk and figure out how to make the commercial >packages actually work would have taken nearly as long as writing my own code. > >The first problem can be solved by what I hope will be the next generation of >super-optimizing compilers that can examine all modules of a project >simultaneously and eliminate code that will never be used e.g. > >main () { printf ("Hello, World!\n"); } > >would end up as 100 bytes because the compiler would eliminate all the code >from printf to handle numbers etc. These super-optimizing compilers are actually performing global analyses to use the CPU resources more efficiently; allocating registers in a manner that is efficient for the program as a whole (as opposed to a manner that is efficient for a loop or function) is one such benefit, but not the only one. If the library is designed well, a new compiler isn't needed to dump the unused code. On the other hand, the unused code is already there, waiting to be used should the need arise. Printf is a special case because of its polymorphism. Here, the compiler would have to recognize the printf call and parse the format string (assuming it is a constant pointer to a constant) to optimize the code. Such optimizations wouldn't be done in many practical applications; national language support enabled applications come to mind here. >The second problem requires an attitude change. And good documentation, with a good index. How many projects like your current one have you done? How much code have you (or others) rewritten? Have you ever turned up bugs in related applications where you had to make the same bug fix in many places? There are three big wins you get from using reusable packages: Your software will (theoretically) be developed faster, because less needs to be written from scratch; Your software will (theoretically) be more bug free because it is built from (theoretically) bug free components; Your program will (theoretically) be easier to maintain because bug fixes need only be made in one place. Some might even argue that your program would be "better" (faster, smaller) because (theoretically) the implementor was expert at implementing the thing at hand, and was able to make various optimizations you wouldn't happen to think of. Finally, come might argue that your program is more portable, because the component has been ported to many platforms (malloc and printf are handy examples of this). What do you think should be taken out? -- Paul Sander (408) 734-9822 | "Passwords are like underwear," she said, paul@Atherton.COM | "Both should be changed often." {decwrl,pyramid,sun}!athertn!paul | -- Bennett Falk in "Mom Meets Unix"