Tips on writing libraries?

From: Michael D. Crawford (crawford_at_[hidden])
Date: 2000-12-28 08:20:03

I'm going to write a web page in which I argue that people don't use
libraries enough, and that they should write more of them, and give some
pointers on how to get started writing libraries.  The web page will be
somewhere around here:

http://linuxquality.sunsite.dk/

Especially helpful would be web pages, either for me to read or link to
from my article, or books, again from me to read or to recommend in the
article.

I think everyone (open source authors or closed source ones) should
write more libraries, but I think the issue is particularly pertinent to
open source programmers because we could get more out of the source
people write if they developed a library when they wrote an application.

If you have the source to an application, it's not too hard to make
special versions of it or to port it to new platforms, but it is
extremely difficult in general to take small portions of code from an
application and make them stand on their own in some other app.  It
doesn't have to be this way, it just usually is because of the way
things are usually written.  If open source programmers developed
libraries while developing their products, it is more likely that their
source can be reused for purposes unimagined when they first wrote the
code.

I got into a debate about this in a discussion on http://advogato.org in
the article "Why is Software So Bloated?" at
http://advogato.org/article/213.html I'm user goingware, user dan said

> If you can write new reusable code and see it actually reused often enough for the extra
> development time to pay off, you're a better programmer than I am. Probably a practising
> clairvoyant, too. 

There are at least two different approaches to writing a library, the
way I see you folks doing it, in which you attempt to produce an ideal,
fully general and rigorously verified solution to some problem domain,
and the way I'm used to doing it that I refer to above - just write a
program, but when one sees a subroutine or class or template that can
likely stand on its own, or that only needs what's in the library
already, then pull it out and put it in the library.

The formal method is of more general purpose and is more likely to
produce a more complete solution to some basic problems.  The second
method is much more ad-hoc and while likely to have holes in it and to
have problems when the library is taken out and used for a new purpose,
I think it's more likely to get more people to contributing code that
way.  I think the ad-hoc way is of use to a company trying to grow a
technology base, and in the open source community this technology base
could be of impressive size and functionality.

A comparison would be the recent boost work on callbacks, which is a
very important and general purpose library, but not really specific to a
given problem, and my work on a recent consumer product, in which I made
it easier to create custom buttons with the GUI toolkit I was working
with.

I think Advogato's dan is write that it is hard to write a truly general
purpose, complete and coherent library - but even so, it is something
that can be learned.  Unfortunately, a lot of programming texts cover
lots of advanced topics and then go on to say "but writing libraries is
much harder than this, and is beyond the scope of this book".  I think
that's wrong - even if writing the _best_ library is hard, libraries can
be improved upon if we have some code to start with, and it's terribly
difficult to extract a library out of an application that wasn't written
with libraries in mind in the first place. 

I'd like to work to improve the situation. 

-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
crawford_at_[hidden]
   Tilting at Windmills for a Better Tomorrow.