Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!taumet!mike
From: mike@taumet.UUCP (Michael S. Ball)
Newsgroups: comp.lang.c++
Subject: Do class libraries have to be in source form? (4 of 4)
Keywords: libraries, source, C++
Message-ID: <179@taumet.UUCP>
Date: 20 Nov 89 15:36:48 GMT
Organization: Taumetric Corporation, San Diego
Lines: 72


Why did I (and others) get upset at the pundits' insistence that
class libraries shouldn't be distributed as source?  I can only
speak for myself, but I would like to hear others' reactions.

1.  The statements are unsupported by fact.  There is no evidence that
    programmers in an object-oriented environment can make good use of
    object-only class libraries, especially for base classes for
    derivation.

2.  The statements were so obviously self-serving.  Most of those
    making such statements hope to sell such libraries.  It reminds
    me of the way successful entrepreneurs like Bill Gates say that
    no-one could do the same thing these days.  It cuts down on the
    competition.

3.  The statements are patronizing.  The implication is that the
    average programmer doesn't need the kind of data he would get
    from the source code.  There were even direct statements to
    that effect.  This is directly opposed to my feeling that we
    should be trying to empower the average programmer, not de-skill him.

4.  The statements might be believed.  Spreading disinformation to
    managers is not a good way to improve productivity.

5.  Such remarks are actively damaging to our purpose of improving
    programmer productivity.  Statements that "object-oriented
    programming means never having to provide source" are the
    modern equivalent of snake oil.  How many shops will try this
    and then conclude that object-oriented programming "doesn't work?"

I have seen it written that there will be two classes of
object-oriented programmers, class designers and class users.  This
is usually coupled with the observation that good class design is
hard.  Of course it is!  Good design of any sort is hard.  However,
You don't make good designers by telling new programmers that they
are too stupid to do design.  You work them into it by having them
work with good designers and study good design.  Since ALL
programming involves design, you can't ignore the issue.

There are those who would like to reduce programming to a mechanical
level.  How many of you remember the big COBOL shops where there was
a strict hierarchy of analysts, designers, and coders?  They didn't
work very well, but they stroked a lot of egos.  Statements that
make little of programmer's skills support this approach and stroke
many of the same egos.

If we need classifications, how about master, journeyman, and
apprentice?  This more closely represents the reality at the most
productive shops.  Members of each group are learning in order to
move up a group.  Keeping secrets from your own students is a sign of
a dead craft.  Programming is too young to die!

I recognize the practical necessity of protecting source code.  We do
it ourselves for our frontends.  It's the code itself that we are
protecting, along with all the work that went into it.  We are not
trying to protect the ideas in it, and in fact devote quite a bit of
time to communicating those ideas widely.  When we sell a license to
the frontend we include training and documentation with the source.
We rely on contracts, not secrecy, to protect our source.

The analogy with libraries is direct.  In both cases we are selling
components which the customer intends to incorporate in his own
code.  We are not selling complete applications.  In both cases
I feel we should work to increase the users understanding of the
product, including the source code.  He is always free to ignore
what he doesn't need.

Michael S. Ball	     		       email: uunet!taumet!mike	
TauMetric Corporation		       Phone: (619)275-6381
1094 Cudahy Pl. Ste 302		       MCI: TauMetric
San Diego, CA 92110