🚀 go-pugleaf

dwiggins> what is the role and task of the "software component librarian"?  

billwolf>To manage an interface between component producers and component users.

I'd like to argue this point.  The interface between component producers
and users should be designed and managed by the component producer.
As in the rest of life, producers are in business only as long as they
satisfy their customers, i.e. the users, so it should go without saying
that producers must communicate a lot with users and should base their
designs on the needs of users.  However, I think that design should be done
by as small a group as possible, and we certainly don't need intermediaries
like a "librarian" who is neither a domain expert or a technology expert.

It is possible that I am misinterpreting "manage".  I see the role of a
librarian as making sure that components have documentation and test suites,
that they can run their test suites, etc.  The purpose of the librarian is
simply to reduce the chaos that would happen if everybody could add and
delete components from the library on their own.  If you only have a
dozen people, it might not be worth the effort to centralize that task.
On the other hand, if you rely a lot on component libraries that you get
from other places then it might be necessary to have someone in charge
of getting new versions and installing them, even if your group is smaller.

I think the orginal question was whether it was worth it to invest a lot
of time and money in a good component library.  Absolutely!  The problem
is in getting good components.  You should certainly grab from the net
those that you can get from free, but I'm skeptical that this will ever
amount to much.  It is probably in your best interest to develop your
own domain-specific components and to buy domain independent ones.  Building
good reusable components is much more difficult than most people let on,
but they are worth the trouble.

In case I have not made myself clear, the question of which components
are needed, whether to buy or build them, which versions to buy, etc.
are NOT the responsibility of the librarian.  These questions are crucial,
and must be the responsibility of high-level technical and management
people.  Perhaps you see a librarian as one of those people.  The name
means something different to me.

billwolf>  Another problem is the existence
billwolf>  of languages which are not standardized and for which no compiler
billwolf>  validation capability exists.
 
This is completely bogus.  There is a great deal of reuse in Smalltalk,
which is not standardized and which has no standard compiler validation
suite.  This is just propaganda for Ada.  There has been a huge amount
of effort put into Ada reuse.  There are only a couple of Smalltalk venders,
and they are all small and poorly funded.  Nevertheless, Smalltalk users
all enjoy a high degree of reuse, but Ada programmers only do if they work
at it.  As far as I am concerned, Ada is no more conducive to reuse than C.

Good programmers can write reusable components in C.  They can in Ada, too.
However, I wouldn't say that either language PROMOTES reuse.