Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.object
Subject: Re: How to pay for reusable software
Message-ID: <1991Apr28.025130.401@odi.com>
Date: 28 Apr 91 02:51:30 GMT
References: <1991Apr3.231849.13410@m.cs.uiuc.edu> <291@dumbcat.sf.ca.us> <396@smds.UUCP> <293@dumbcat.sf.ca.us>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 50
In-Reply-To: marc@dumbcat.sf.ca.us's message of 20 Apr 91 05:25:50 GMT

In article <293@dumbcat.sf.ca.us> marc@dumbcat.sf.ca.us (Marco S Hyman) writes:

   If these programmers were too lazy to learn their own programming environment
   what makes anyone think they will read the library manuals?  Portability is
   not the issue here.  More libraries just leads to more documents not being
   read.

That's a very good point.  I'd like to extend it.  I was one of the
first users of the original Emacs at MIT.  When Emacs was first
gaining popularity among some people, other people frequently objected
to Emacs, saying that its biggest problem was that it "had too many
commands".  Now, there was no need for any user to learn all of those
commands, and certainly no need to learn them straight away.  You
could edit quite reasonably using no more than 25 or so Emacs
commands, and never learn any more if you didn't want to.

The reason Emacs had so many commands is that it contained a large
library of reusable functionality.  Some users liked this a lot, and
learned quite a few of the commands.  But it was very interesting to
see how others never bothered, and some were actually put off by their
presence.

Your comments above made me realize that there may be a useful analogy
between this phenomenon and the issue of large reusable code
libraries.

It takes time to learn how to use a reusable library.  You have to
read the documentation, and try it out a bit, and get some experience
and familiarity.  All this is a like capital investment: you have to
spend time directed not towards your immediate objective, with the
idea that over the long run, you'll be paid back many times over.  So
you have to be convinced that the library is worth the effort of
learning it.  But it's often very hard to know in advance how hard the
library will be to learn, and how much trouble it will save you.
Sure, when you know that you need to solve linear equations, and
there's a library routine lying around that's well-debugged and
numerically stable, you'll know.  But it's not always so obvious.

It's also a matter of preference.  I like learning to use reusable
software and functionality; the learning itself is fun.  Not everyone
feels that way.  And when I'm in a hurry and under pressure, I
sometimes don't feel that way.

The real point is that making libraries that will really be accepted
and used is not only a matter of the actual writing of the software,
and the software technology (such as parameterized types), even though
these things are quite important.  You also have a lot of real-world
human issues to deal with in order to make these things easy and
enticing and so on.  I hope we'll all learn more about how to succeed
in these matters as well.