long names in 'C' programs

[J. Eric Roskos]

While I don't read net-lang.c presently, and REFUSE to participate in
net.unix-warriors ... uh... wizards, this discussion has leaked into
net.sources.

The posting 668 at mcvax is an example of the "All the World's a VAX" attitude
which was discussed recently in the Usenix paper "Can't Happen, or, /*
NOTREACHED */, or, Real Programs Dump Core," by Ian Darwin and Geoff
Collyer.  This unfortunate attitude dogmatically assumes that one's present
machine is the be-all-and-end-all, and that thus whatever exists on one's
present machine should therefore be what exists on everyone else's system,
and if it isn't, well, they are just behind the times and need to catch up.

But this attitude is myopic and ridiculous.  Authors of programs posted to
net.sources should not be in the business of trying to force everyone else
to adopt whatever extensions to the language exist on their particular
machine.  That's what's basically wrong with the statement:

> But now suppose you got such a program every week. Wouldnt you
> instead buy a better compiler/loader?

It assumes that a better compiler/loader exists for their machine, that one
can afford to purchase such a compiler/loader, or that one can influence
the purchase of a new compiler/loader just because some public-domain
programs show up that require it.

The list the author then gives indeed documents a number of things people
should watch out for in writing portable programs.  Unfortunately, the author
concludes that one SHOULD use exactly these, in order to bludgeon people into
adopting the new extensions.  This is unreasonable.  You have to accept the
fact that many users don't yet have these features; maybe they are just a
small business, or a small college with a yearly equipment budget of $7000
per year, or maybe just some students who have to make do with whatever
machine their university supplied them.  You can't really force these people
to change in the short run.  Either you have to have the courtesy to use
wisdom in programming, or have your program not be used by them.  But the
philosophy expressed in the article I am commenting on is roughly equivalent
to the statement

	I drive a Honda Accord, which as a 3-barrel carburetor.  I think
	we should quit making anything but 3-barrel carburetors, because
	they are the state-of-the art and if we do that, soon all car
	manufacturers will use them too.

It's simply an issue of compatibility.  Unless you want to make your users
suffer unnecessarily, you should introduce new changes gradually, and wait
for the old ones to die out gracefully, rather than forcing new features
on the user.  If the new features are truly worthwhile, they will, in time,
find their way into all compilers.  This is a hard problem to deal with,
but it is simply the reality of practical programming in the real world.

----

[I guess a disclaimer is required here.  The above is my opinion, and does
not necessarily reflect that of PE.  Actually, PE's compilers support all
the new features the author listed, to my knowledge.  My comments are based
on the fact that I recently attended a college which had an old Edition 7
system, with an "old" compiler, simply because their budget was not
adequate to go purchasing new compilers until the features of them were
well established and standardized; which, in their case, will probably be
when they buy a new machine.]
-- 
Full-Name:  J. Eric Roskos
UUCP:       ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail:    MS 795; Perkin-Elmer SDC;
	    2486 Sand Lake Road, Orlando, FL 32809-7642

	    EKE.  Jngpu bhg sbe gur pnef.