Path: utzoo!utgpu!watmath!att!rutgers!ucsd!swrinde!cs.utexas.edu!uunet!dino!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson From: johnson@p.cs.uiuc.edu Newsgroups: comp.sw.components Subject: Re: What should a component library loo Message-ID: <130200021@p.cs.uiuc.edu> Date: 17 Nov 89 01:30:51 GMT References: <89@ Lines: 54 Nf-ID: #R: 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.