Re: Problem trying to implement generics.

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Tue, 17 Apr 2001, Marin David Condic wrote:
> I've been an on-and-off C programmer for a *lot* of years. I'm currently
> doing nothing but C programming. 

You have my condolences. 

> I dislike the various C shorthand operators and don't use them because
> it is not immediately and intuitively obvious to even the most casual 
> observer what it is they are doing. 

It's not obvious to the most casual observer what any program in any
programming language does, or what the meaning of a legal contract is, 
or whether a PDE is elliptic, parabolic, or hyperbolic, or the difference
between a pin and and x-ray attack in chess, etc. ad-infinitum,
ad-nauseum. 

Every good programmer who uses C will learn what those shorthand notations 
means. Other languages, even clean slate ones like Icon, have copied some
of those shorthands. I find them equally readable to Ada's long winded
expression. This is a bad example of a C problem. 

 Most programmers
> can recognize the basic algebraic notation that is common to almost all
> popular programming languages (your basic "Y = M * X + B" type of thing) and
> so I use that type of expression in (almost) all C programming contexts. (I
> don't think I need to mention all the possible problems that come up in the
> more clever uses of esoteric features like the difference between "++X" and
> "X++" - but I guess I just did. People who use *that* kind of thing should
> be turned into castrati so that they start singing a different tune. :-)

I agree that there's a fine line. But I'd prefer the shorthand line 

Some_Long_Variable_Name++; /* A C programmer would write slvd++ ;-) */

or even 

Incr(Some_Long_Variable_Name); -- how's this? 

or 

Incr(Some_Long_Variable_Name, Delta => Increment); 

to this 

Some_Long_Variable_Name := Some_Long_Variable_Name + 1;

and I think it makes sense in a programming language to have shorthand for 
very commonly occurring operations. 

For instance, I really wish some future Ada would add << and >> for bit
shifts. 

> I've had the debate with various associates which usually starts out with
> "Any *competent* C programmer should be able to....." My retort is always:
> "How does it make me money when a less-than-"competent" C programmer has to
> decypher it?" 

IMO, a good example of this is writing string or array traversals by
using pointer offsetting. Yuck! Using arrays is much clearer. 

> Every minute spent trying to figure out what an expression does is a
> minute *not* spent making money for the stockholders. 

Well, that's a good argument for removing floating point from most
programming languages too ;-). Please read some of William Kahan's work if 
you don't get the joke...

> even the slightest possibility that someone can misinterpret what the
> expression means or possibly get the syntax wrong or otherwise botch things
> up, then it ought to be avoided. (Assuming one has a simpler, more obvious
> representation for the same thing. After all, there are those who will have
> trouble understanding "Y = M * X + B" but I'm not sure I can make it much
> simpler for them. At least if they know some Fortran, Pascal, Ada, <insert
> language here>, chances are they won't have much trouble guessing what that
> sort of expression means in C.)

C is a different language from Fortran, Pascal, and Ada. I wouldn't hire
an Ada programmer who knew only the Ada/Pascal/Fortran/C intersection of 
features. I wouldn't hire a C programmer who refused to learn C, and
insisted on working in some pidgin Algol subset. 

> The "+=", et alia, were basically invented by people who couldn't type. I'd
> rather opt for the clarity in the expression and not worry about all the
> interesting ways of representing it in fewer keystrokes. After all, on any
> given day of the week *I'm* not a "competent" C programmer! 

I guess there must be something about Ada that makes people into very bad
C programmers. I wrote my first little C program in about a year a few
days ago, and I tripped up on the argc, argv indexing but not on the 
shorthand operators. Go figure.

> I don't want to work that hard to understand what
> I did yesterday when I was fully awake.

I'd find these anti-C arguments would be more compelling if I'd observed
these problems in my own C programs. I haven't. The most interesting
comments were on the lack of a matching lexeme for closing {} and
L. Guerby's comments on how C's semantics lead to debugging nightmares. 
Oh, I'd also say that flat languages (no nesting + lexical scope) suck. 
But C syntax and shorthand operators are not all bad. 

-- Brian