Path: utzoo!attcan!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!vax1.tcd.ie!rwallace From: rwallace@vax1.tcd.ie Newsgroups: comp.sw.components Subject: Re: What is a reusable software component? Message-ID: <6775.26cdc403@vax1.tcd.ie> Date: 18 Aug 90 22:41:06 GMT References: <27705@athertn.Atherton.COM> <533@helios.prosys.se> <27914@athertn.Atherton.COM> <6729.26c481cb@vax1.tcd.ie> <28772@athertn.Atherton.COM> Organization: Computer Laboratory, Trinity College Dublin Lines: 155 In article <28772@athertn.Atherton.COM>, paul@athertn.Atherton.COM (Paul Sander) writes: >>> 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. > As far as I can see, what you're saying is that packages shouldn't' be made to do everything, they should be made expandable so that people can add the features they need. I agree with you there. >> 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. Some of it but by no means all. Look at the source code for any reusable component written by someone else. Think about a typical use, e.g. a screen package for accounting software: it will have facilities for handling movable resizable windows in graphics or text mode, with handling of carriage return / linefeed characters, beep characters, probably ANSI codes to boot and most of this will be in the core code. The linker can do a very limited amount to eliminate unused code. > >> 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. > In the library yes. However for the reasons given above, with current compilers it'll be in the executable as well, wasting space. > 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. > I don't agree. I think reusable software components could be useful in most applications, but to produce acceptable efficiency such compilers need to come into general use. >>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 thi By and large the documentation for modern development software is excellent, but no matter how good the documentation you're going to have to do some experimentation and the more complicated the product the longer it'll take to figure out how to use it. Admittedly this is by far the biggest project I've ever worked on but my answers to your points are as follows: 1. _The_ advantage of reusable software components is that it reduces software development time, at least if the tendency to overcomplicate things is controlled. As I explained, this advantage is becoming less and less relevant as developers put more and more unnecessary junk into their products. 2. I can make my routines as bug free as a reusable component developer, and consider: If there's a bug in one of my routines, I can fix it on the spot. If there's a bug in a routine supplied by someone else to which I don't have the source, I have to wait for an upgrade. 3. Two examples: First, screen display routines. My routines are much more efficent than anyone elses because mine just transfer data direct to video RAM while other people's routines have to cope with things like linefeed and beep characters. Second, sort routines. Admittedly the third party routine under consideration was faster than mine for merge sorts too big to fit into memory, because they'd spent a lot of time optimizing the algorithm. However for sorts that fit into memory (almost all in the application in question) my routine is faster because there's less junk in it. To answer your last point: malloc() and printf() are part of the language standard. Third party packages may only be available on some systems. This project is being developed on MS-DOS with a view to porting to Unix. What if I used a third-party routine not available on Unix? My own routines can be ported to Unix in a few hours (at least in theory :-)). From the binary tree package which was originally under discussion: I can't remember most of what was in it but I think the facility for N-way trees should be removed because it won't be used in most cases (none that I can think of) and it reduces efficiency. (After all the whole point of binary trees is their efficiency compared to linked lists!). Sorry if this posting is a bit garbled, I'm using terminal emulator softwar which doesn't work very well with this editor. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@vax1.tcd.ie