mike@taumet.UUCP (Michael S. Ball) (11/20/89)
The final session of the recent "C++ At Work" conference was a panel
of "experts" discussing the future of C++. Several members of the
panel spoke at considerable length about the future market for object
code versions of C++ object libraries. They also claimed this was
going to improve productivity enormously. After listening to it for
quite a while, I got fed up and (loudly) stated that I thought this
was so much garbage. The experts, of course, all disagreed with me,
but many attendees told me afterward that they agreed strongly. I
let this sit for a week so my initial strong emotional reaction had
time to die down. I think there are still several questions worthy
of wider discussion.
1. Are object-only versions of class libraries a good idea.
2. Why to vendors of class libraries want to distribute object-only
versions rather than source code.
3. Why did I (and others) have such a negative reaction to the
expert pronouncements.
I am posting three articles on these three topics in hopes of
stimulating further discussion. To establish my "bona fides", I am
the author of the first C++ frontend implemented outside AT&T, and
have closely studied every scrap of C++ code I have been able to
find. I have also supervised the development of a class library
(still incomplete) but I have never tried to make heavy use of an
existing class library on a large project.
Michael S. Ball email: uunet!taumet!mike
TauMetric Corporation Phone: (619)275-6381
1094 Cudahy Pl. Ste 302 MCI: TauMetric
San Diego, CA 92110mike@taumet.UUCP (Michael S. Ball) (11/20/89)
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 92110richard@pantor.UUCP (Richard Sargent) (11/21/89)
> From: mike@taumet.UUCP (Michael S. Ball) > Message-ID: <176@taumet.UUCP> > Date: 20 Nov 89 15:32:31 GMT ... > > 1. Are object-only versions of class libraries a good idea. > > 2. Why to vendors of class libraries want to distribute object-only > versions rather than source code. > > 3. Why did I (and others) have such a negative reaction to the > expert pronouncements. > Note: this is not the definitive Answer. However, I am a software developer and I work for a company which markets software. What a company believes and what is reality are seldom the same thing. In general, I do not have the time, inclination, nor the funding to deal with source code for libraries. Essentially, I want to buy a product which works and *use* it. My experiences are with C rather than C++, so there may be fundamental differences of which I am unaware. There are a number of reasons why vendors do not want to release source code. They include "proprietary technology", fear of abuse of their efforts (regardless of the illegality of such), no desire to be responsible to support the source (sure, they can disclaim), a desire to keep their dirty linen out of the public view (would you like people looking at everything you ever wrote?) as this could result in negative marketing considerations, etc. The last, for example, could be something like the code was hacked together, but works and works well. They don't want you to be put off by its appearance. They want to sell lots of copies instead. It is immaterial whether that is a good thing for you. One of my coworkers always buys source with any libraries he gets. He wants the option to fix their bugs rather than wait for fixes. He wants to be able to learn how they do something tricky. etc. In a university environment, where source licensing is common, people may have strong objections to not being able to get the source. *If* you have carried such an attitude into the commercial world, that may be one of the reasons you object so strongly. I am not claiming that you have, but rather I am identifying one possible reason. Certainly if the market puts enough pressure on vendors to supply source, they will bend. They are in business to sell products and make money. Expect to pay heavily for the priviledge. In any event, the vendors which best provide what we need will prosper. Richard Sargent Internet: richard@pantor.UUCP Systems Analyst UUCP: uunet!pantor!richard
dxb@genrad.UUCP (Daniel A. Burkhard) (11/22/89)
In article <176@taumet.UUCP>, mike@taumet.UUCP (Michael S. Ball) writes: .... stuff deleted > time to die down. I think there are still several questions worthy > of wider discussion. > > 1. Are object-only versions of class libraries a good idea. > > 2. Why to vendors of class libraries want to distribute object-only > versions rather than source code. > > 3. Why did I (and others) have such a negative reaction to the > expert pronouncements. I fully agree with mike in all points he made to 1.) and would like to add the following: Class libraries are different from "function libraries" in that they include a higher degree of design, that is a hierarchy. The design of software system should be tailored to the specific problem and not to a tool (library) used to build it. I certainly do not want to adopt ONE vendors design philosophy just to be able to use the library he is selling today. Some people develop software for exotic CPUs/OS. I wouldn't rely on the class library "X" to be 100% compatible with my environment. I don't expect the vendor to be interested to port to my environment, I can't wait for the port, I don't want to spend the money, I don't want to wait infinitely for bug-fixes .... . Not responding to these needs, means neglecting a large market segment (remember: C++ is a systems programming language). I have no additions to 2.) To 3.): Telling a potential customer that he is to dumb to ever being able to understand what the gurus (at microsoft) developed, therefore he (the customer) never ever wants to know what he bought, just turns me off. I have yet to see documentation that fully replaces source! ------------------------------------------------------------------------- Dan A. Burkhard e-mail: dxb@genrad.com Genrad, Inc. Phone : (508) 369-4400 X3304 300 Baker Ave. Concord, MA 01742
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (11/22/89)
In article <29023@genrad.UUCP> dxb@genrad.UUCP (Daniel A. Burkhard) writes: >.. I have yet to see documentation that fully replaces source! That's because source IS documentation! I will freely cast my aspersions on any assertions that it should not be the BEST documentation. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
horstman@sjsumcs.sjsu.edu (Cay Horstmann) (11/22/89)
I will not purchase a library that doesn't come with source. I develop PC based software, and several of the tools that I used came from VERY small vendors. If I have source and the vendor goes under, I can recover. Realistically, I rarely make changes to library code. It just is too much of a pain to transfer the changes to the next release. I would also believe that a library with source would be of higher quality since the vendor would presumably be embarrassed about passing lousy source to their customers. (I have been proven wrong in this aspect.) There is the learning aspect too. I have learned a lot from looking at library source.. At least in the PC world, it is ludicrous for a vendor to say that source availability increases software theft. Software theft, whether object or source, is only an XCOPY away, and the only protection a vendor has is to provide an on-going service to the customer. That of course requires a lot more commitment than a $$$ <----> .obj trade. I would not want to work with a vendor only interested in the latter. Cay
mike@taumet.UUCP (Michael S. Ball) (11/23/89)
Someone pointed out to me that I gave the impression that everyone on the panel disagreed with me. That's definitely untrue. There were only a few who got my goat. Some members made quite good comments on C++ and its future. I just wanted to set the record straight Mike Ball
davidl@hpcll11.HP.COM (David Leger) (11/23/89)
In article <taumet.UUCP> taumet.UUCP (Michael S. Ball) writes: >.. 2. Why to vendors of class libraries want to distribute object-only > versions rather than source code. Could it be because they fear the support issues for software created from the (modified) library source? David. ---------------------------------------------------------------------------- - "There is a fine line between feeling 'the challenge', or just being lost." David Leger
marc@dumbcat.UUCP (Marco S Hyman) (11/23/89)
I've thrown away my three previous responses to <176@taumet.UUCP> but can not restrain myself any longer. (Oh, oh. I'm getting on my soapbox again). In article <176@taumet.UUCP>, mike@taumet.UUCP (Michael S. Ball) writes: 2. Why to vendors of class libraries want to distribute object-only versions rather than source code. Many companies believe that their secretiveness gives them a competitive edge. In a way they are right. If they distribute the source to their libraries then everybody could learn what they know and they would therefore have to compete on price, or service, or by staying ahead of the competition. A scary thought. (That's something you have to be succussful to do). Secrecy is the way we do business. Control of information is power. An example of this point of view is the way business looks at patents. Congress has the power "To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.'' U.S. Constitution, Article I, Section 8. Patents are a bribe: you share what you have learned/invented and we'll give you exclusive rights -- even if someone else discovers the same thing independently -- for a limited time. However, business doesn't think of a patent as sharing information. It's a way to limit competition. Power. It's a wonder that any vendors do distribute source. In article <29023@genrad.UUCP> dxb@genrad.UUCP (Daniel A. Burkhard) writes: I have yet to see documentation that fully replaces source! As long as I'm on my soapbox... I have yet to see source that fully replaces documentation. Actually, that is a lie. Literate programs fit the bill. Is anybody out there working on tools for ``Literate C++'' ??? // marc -- // Marco S. Hyman {ames,pyramid,sun}!pacbell!dumbcat!marc
shap@delrey.sgi.com (Jonathan Shapiro) (11/24/89)
I don't want to be misconstrued as advocating this approach, but some other environments, including the SmallTalk and forth folks, have come up with some possibilities here. One way is to ship libraries in a universally agreed intermediate form, such as some threaded-interpreted code. As the code runs, it self-compiles, using an implementation-supplied compiler, and replaces the interpreted code. Alternatively, one could target-compile it at the site. Jonathan Shapiro Silicon Graphics, Inc.
yh87@mrcu (Paul Johnson) (12/04/89)
>.... >One way is to ship libraries in a universally agreed intermediate >form .... >... Alternatively, one could target-compile it at >the site. > Actually most C++ compilers and Eiffel already do this. The intermediate form is called "C". Paul. -- Paul Johnson.---------------------------------------------------------------- GEC-Marconi Research are not | Don't worry: Baldrick has a Cunning Plan! responsible for my opinions. | (Graffiti on East side of Berlin Wall) -----------------------------------------------------------------------------