Re: Long names are doom ?

[Pete Thompson <blackpete@nowhere.somewhere.anywhere.com>]

On Wed, 6 Jun 2001 11:25:28 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote:

<snipping of mostly agreements>


>I like the first better. But I dislike things like I++ - not so much that
>particular one, but all the subtle variations that can take place. It
>changes meaning if it is in front or behind - but that only makes a
>difference sometimes. It can be mixed with other interesting variations and
>things like +=, etc. In the end, the "terseness" possible with this kind of
>operator is just plain not worth it. Way too subject to abuse. Way too easy
>to misconstrue meaning in complicated cases. Often ambiguous in definition

Well, sure it's subject to abuse.  However, that's the fault of the programmer,
not the language itself.  I too froth at the mouth whenever someone makes a
stupid use of operator overloading in C++, or write unnecessary compound
statements.

>leading to "implementation dependent", reliant on side effects, Etc. So to
>save the few keystrokes needed for "I := I + 1 ;" I give you "I++" and open
>the floodgates for the "Betcha can't guess what *this* line does!!!" kind of
>coding. Better to be rid of it and insist on the few extra keystrokes needed
>for Fortran-ish expressions and avoid all the trouble that will inevitably
>come from that programmer who will insist that "It should be intuitively
>obvious to any *COMPETENT* C programmer..."

Maybe I've just been lucky enough to have never worked in a workplace with
programmers like that who insists on trying to look clever in their code, and
thus I have no problems like that.  Should I be forced to move on to a more
verbose language because other people had bad experiences? 

>> Hmm.. I'd have to say that I agree and disagree.  It really depends on
>what
>> industry you're in.  If you're in the kind of industry where you're hiring
>> newbie programmers all the time, then yes, it's important to be as
>explicit as
>> possible.  However, there are industries where programmers MUST be
>experienced
>> before they're hired.  Does it really make sense to make your code as
>> newbie-ish as possible for them?  (Again, without being cryptic).
>>
>Here's the issue: (And there's no way of getting around the question.) How
>is it that this MAKES MONEY FOR THE STOCKHOLDERS? (Sorry for shouting.)

You have deadlines.  Miss the deadlines and you're going to piss the
stockholders off.  More experienced people are generally faster than newbie
coders, and new hires with experience tend to hit the ground running faster.
No need to wait for them to learn the ins and out of the API that your company
happens to be using, if they already know it.  I'll explain more below.

>All industries hire newbies. Even experienced programmers are newbies to
>your code - otherwise they aren't new-hires. If I write simple, direct,
>straightforward code with good comments, good structure, good documentation,
>etc., then I've got code that a newbie to Language XXX can readily read and
>grasp (hopefully). Does it *HURT* the experienced programmer that you didn't
>write something in as few keystrokes as possible within Language XXX? I
>don't think so. (Like I said, whenever someone else picks up your program

If you're asking for my personal experiences, then yes it would hurt everyone
(including the shareholders and customers) if I needlessly broke the code up
into multiple statements that used up more clock cycles, especially if it's a
piece of code that needs to be called often.  I work in the gaming industry.
Speed is king.  Just make damn sure that you comment your algorithms.
Unfortunately, people do tend to try to be needlessly terse and cram many
instructions into a single line because they think that's a good way to
optimize when it in fact accomplishes nothing.

When hiring new people, we expect them to know at least the basics of the API
we're using  (DirectX, OpenGL, whatever), some 3D math, and some of the bells
and whistles.  We've got deadlines.  We can't afford to hire pure newbies.  A
certain level of experience is a must.  And yes, we do look for people with
good coding practices -- no sloppy stuff, please!  That'd just slow down the
other team members.  We once had a vacuum salesman with no programming
experience applying for a job... want him?  :)   Of course there are the odd
times when we do hire programmers from another industry, but we generally stick
them with the task of creating tools and utilities until they learn the gaming
fundamentals. Sometimes they're quite happy with creating tools, and never want
to work on games directly.

If I was working for, say, a bank, then yes I would write slow and reliable
code that would last for years and be easily readable by people 10 years down
the road.  If I was writing software for a weapons research facility, then I'd
be sweating over every line and be agonizingly descriptive (/* here is the
auto-destruct function.  I say again, here is the auto-destruct function.
WARNING! Danger Will Robinson Danger! */). 

However, working in the gaming industry is a bit unforgiving in the sense that
your code generally becomes obsolete fairly quickly.  Just about the only thing
we can keep from project to project are the libraries, interfaces, and
platform-independent functions, and even they may need changing as new
platforms ship.  Spend too long programming, and your game becomes obsolete
before it even ships, like a certain over-hyped game...
*cough*Daikatana*cough*.  As such, writing long-term code is a bit of a wasted
effort (unless if it's REALLY useful and generic such as a quicksort function),
and that time would be better invested in tweaking the eye-candy to attract
more customers.


>Read before what I said about opening up the floodgates. Some features of a
>language are *inherently* unsafe or encourage obfuscation or make it easy to
>introduce errors. In C (and in a number of other languages) you have well
>known "syntax traps" that make it easy to create compile time errors that
>are hard to locate. Similarly, there are "semantic traps" that make it easy
>to introduce run-time errors. (BTW, this is true of verbose languages like
>Cobol as well). I'm in favor of structuring the notation of a language such
>that it minimizes the risk of errors and maximizes the communication to the
>reader. IMHO, C's terse notation works against these goals. C's semantics
>work against these goals as well, but that's another debate.

Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and encourages
obfuscation.  However, it also promotes flexibility.  That's always been an
acknowledged trade-off in C/C++ - with flexibility comes responsibility.  I
don't see how you can clean up the notations to reduce bugs, though, short of
getting rid of pointers altogether (which I definitely DON'T want to see happen
in C/C++).  


>I hear you. I agree with this. I'd prefer a language design that does not
>ALLOW something like what you just described, no matter how much "expressive
>power" can be gained for the attainment of Good And Noble goals. (Sort of an

Well.. it's always hard to predict how creative the programmer can be.  Java
was supposed to be "clean"... of course it didn't take too long for people to
prove otherwise  :)    On the flip side, be too restrictive, and you could end
up with a dead language.  People complained about Pascal because it was so
"structured".

It really depends on the programmer - like you said, anything can be taken to
the extremes, and even the greatest language in the world can end up looking
horrible in the hands of a talented (ahem) programmer, and there's not much we
can do to "fix" this.  I've accepted this about C/C++:  I know it's not
perfect, and I do bitch about it off and on, but it works well for me for what
I need to do. 

A hammer's just so damn useful, but I still sometimes hit my thumb.