🚀 go-pugleaf

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