Topic: Compiler Economics 101 (was: Prefix versus postfix operator overrides)


Author: jaf3@ritz.cec.wustl.edu (John Andrew Fingerhut)
Date: 8 Aug 1994 15:07:28 -0500
Raw View
In article <rfgCttLyA.KE4@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>I happen to be one of those ``end-user'' programmers myself (and I
>don't sell compilers) so I agree with you 100% that *I* need to make a
>profit.  What we disagree about is whether or not new features save me
>money or cost me money.  I think the fundamental laws of economics make
>the answer pretty clear.
>--
>
>-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
>---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
>---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

This reminds me of what my jeweler said when I was buying an engagemnt/wedding
ring for my fiance (now wife).  The ring set that I liked as a wedding set
looked lopsided as an engagement ring.  Yet I wasn't able to find a nicer
wedding ring.  He said that before dismissing the ring because of the
"lopsided appearance" of the engagement ring, consider how long it will be
worn without its wedding ring counterpart.  She has been wearing a beautiful
wedding ring for 8 years now after only 6 months of the lopsided engagement
ring.

The point is, let's have the thing right after the standards committee gets
done.  The pain we suffer for the short term is well worth the beauty in the
long term.  (That's not to say that I believe that every extension has made C++
beautiful ;-).

Stephen Gevers
sg3235@shelob.sbc.com




Author: rfg@netcom.com (Ronald F. Guilmette)
Date: Sun, 31 Jul 1994 19:54:10 GMT
Raw View
In article <CtLw5J.K4t@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <rfgCtLBzL.DBo@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>fact, the implementors (and representatives from compiler vendors) on
>>the committee... i.e. the people who actually have a detailed under-
>>standing of how tough it is to implement (and *test*) all this stuff
>>have, in general, been very responsible in recognizing the *actual*
>>costs (both to themselves and to end-users) of each new addition to
>>the language.  It's all those *other* folks who *know* that they'll never
>>have to do any of the painful, slow, and laborious work to implement
>>and test any of this stuff that always seem to insist on having just
>>one more feature... and then just one more after that, etc.  (And as
>>bad luck would have it, these non-implementors heavily outnumber the
>>real implementors on the committee. :-(
>
> I should point out that as a _user_ of the language C++,
>I'd rather a few professional implementors slave over getting
>their implementations of powerful features right...

As is quite often the case in these debates, your side, John, seems to
have totally missed the point being made by the other side (which, at
the present moment, I am trying my best to represent).

You speak of implementors, slaving away over their implementations, as
if this activity was occuring on some other planet (or perhaps some other
parallel, but disconnected universe), and as if this ``slaving away''
has no relationship to, or effect upon you, the average end-user.

But this is exactly that central falacy which I have attempted to dispel,
i.e. the falacy that you, as an end-user, can get a free lunch.

Well, John, I'm here to tell you that there is no such thing as a free
lunch, no matter how much you wish you could have one.

Every additional feature which has been jammed into this language has
ultimately had an effect upon you, the end-user, although you may not
be directly aware of it.  Acatually, there are several such effects,
and few of them are the kinds that you would like.  Sure, with every
new feature, you get some (marginal?) amount of additional expressive
power.  But if you open your OTHER eye, you may notice the downside of
these things.

For one thing, every new feature delays the standard (by some incremental,
perhaps modest amount).  These delays (in the production of the standard)
further push back the date when you can actually *use* all of these nifty
additional features in programs which you might desire to port from one
platform to another (or even from one compiler to another on the same
platform), because the vendors can't really *conform* to the standard
until there *is* a standard.

For another thing, every new feature added to the language has to be built,
tested, and documented by at least one compiler vendor before you get to
use it.  Now you may believe that this is *their* problem, and that it
has nothing to do with you, but if you have ever hesitated to use some
new feature (e.g. namespaces, RTTI, mutable, etc.) because your compiler
of choice just didn't have it yet, then you should at least understand
that these things just don't show up immediately.  More to the point,
when they *do* show up, they really don't come to you for free.  Either
the price of compilers goes up (which it has to, in order to make up for
the additional development, testing, documentation, and support costs)
or else the marketplace keeps the costs of the compilers artifically
low, e.g. below the actual cost to produce them, and you end up having
most of the compiler vendors go broke.  Then, after awhile, you will be
left with the normal oligopoly situation typical of ``mature'' industries,
were the few remaining players can pretty much set their prices in tune
with one another, and where you, the end-user, pay through the nose for
any one of the few remaining (survivor) products.

It's really rather a pity that John, and so many other folks, still harbor
this strange delusion that there is something so unique about C++ compilers
(or about the marketplace for said compilers, or about the volume of
compiler vendors versus the volume of compiler end-users) that it will
somehow magically repeal one (or more) of the fundamental laws of econ-
omics... most notably the TANSTAAFL law -- ``There ain't no such thing
as a free lunch.''

Normally, I don't mind seeing people delude themselves (as long as they
do not also try to delude me) but when it comes to C++ (and the never-
ending calls for just one more little feature) I'd like really to get
people to understand that the addition of each new little feature drives
up the cost of compilers for me (as well as for them), as well as the
cost of CASE tools, seminars, training classes, and books.  And oh, by
the way, I've been forced to throw out most of my C++ books becase even
the ones that were published just two short years ago are already obsolete.
I'm sure this news comes as a great comfort (even if no great surprize)
to the authors and publishers...  who now get to sell me all of their
*new* books... but I can't say that I like watching $30-$50 bucks head out
the door to the recycling center, just because a few more people decided
that there were a few more things that they just couldn't write programs
without.

> So there are two sides to the coin: it is not only
>vendors that have to make a profit but programmers too.

I happen to be one of those ``end-user'' programmers myself John (and I
don't sell compilers) so I agree with you 100% that *I* need to make a
profit.  What we disagree about is whether or not new features save me
money or cost me money.  I think the fundamental laws of economics make
the answer pretty clear.
--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -