Re: Long names are doom ?

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

"Pete Thompson" <blackpete@nowhere.somewhere.anywhere.com> wrote in message
news:35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com...
> Hmm in that case, I should give you my sister's phone number.  She can
talk for
> well over two hours on the phone before finally getting to the point  :)
>
Verbosity for the sake of being verbose is as dumb as terseness for the sake
of being terse. Whatever you put on paper needs to say something *useful* to
the reader and do so in a *clear* manner. Verbosity or terseness must be
used to serve some higher goal - not become goals in and of themselves.

> I feel the same way about code:  being verbose is all well and good, but
> pointless verbosity can do more harm than good.  It tends to hide the
overall
> picture as to what the function/application is *really* doing.  It makes
the
> function look more complicated than it really is.  It leaves you wondering
if
> you're somehow missing something because there's more to read than is
really
> necessary.
>
We agree here. I think that again I'd emphasize that it is neither verbosity
nor terseness that makes something clear to the reader. Clarity of thought
and expression are not going to come from either terse or verbose notation.
First the thought has to be clear. Then you have to find a way of expressing
that thought in a manner that will be understood by the audience.


> As Roedy mentioned in some other message, it's a hard one to pin down
since
> it's such a subjective matter.  Maybe it's futile to even try.
>
There is some subjectivity to it, but I would say "not entirely" I think
that the notation in C is entirely too terse and subject to way too much
abuse. Likewise, I think the syntax of Cobol is way too verbose and
needlessly obfuscates with TMI. (Who thinks that "Add Gin To Vermouth Giving
Martini." is somehow a better idea than "Gin := Vermouth + Martini;" ?)

> Which one of the following do you prefer:
>
> i = i + 1;
>
> or
>
> i equals i plus one.
>
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
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..."

> Imagine a whole program written using the latter method.  Would that
really be
> much fun to read?  Compound statements would be nearly unreadable.
>
Imagine? Don't need to. Been there. Done that. Its called "Cobol
Programming"


>
> 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.)

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
for the first time, they are a "newbie") Anything I do to help the newbie
understand what is going on is at worst, not going to hurt the experienced
programmer and at best will probably help him along as well.

Now there are some things which are inherently complicated. If I need
multitasking - that's going to be tough to express simply because it isn't a
simple thing to do. Can't help you there by picking some kind of notational
syntax perceived to be "better". I think it was Einstein who said "Things
should be made as simple as possible - but no simpler." I guess what I'd
prefer to avoid in a language syntax are the obvious pitfalls that
repeatedly create errors and inevitably cause confusion and
miscommunication. Doing that much accomplishes something. It will never make
E := M * C**2 ; be as simple to understand as Y := M * X + B ;


>
> Well, that's sort of going to the extreme.  If the syntax is a part of the
> language itself, then it should be readable by anyone well versed with the
> language.  "i++" is not cryptic since that's a part of the language.
>
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.


> If it's a "clever" (ab)use of the language, then you may need to
reevaluate
> what you're doing.   I hate it when people try to cram 4 or 5 or more
different
> things into the same line.  I just love reading stuff like c = a+++++b.
(not)
>
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
"ends justifies the means" argument?) Just because someone might rarely (and
arguably) use this sort of notation to express something in a clear and
concise manner, does not mean I want to frequently (and not so arguably) see
these kinds of attrocities committed either because someone a) thought it
was "clever" or b) thought it was "Intuitively Obvious To Any *Competent*
Programmer" or c) both.

One of the reasons I like Ada so much is because the syntax and semantics
tends to avoid such obfuscations. Its not that you *can't* write bad code in
Ada. (nor is it hard to write "concise" code - as long as we aren't simply
counting keystrokes as the measure of "conciseness") Its just that it tends
to steer you towards more straightforward and direct expression of what you
intended to do. It also does an enormous amount of error checking and
disallows certain things that cause errors commonly. The syntax also avoids
common "syntax traps" found in other languages & makes it easier for the
compiler to pinpoint exactly where you mistyped something. If you can't
write good code in C, you aren't magically going to start writing good code
in Ada. However, I think Ada provides a lot more help to the programmer who
is capable of writing good code.


> I guess we're pretty much arguing the same thing at this point.  My own
> contention is that there are programmers who are needlessly verbose that
the
> code looks more complex than it really is.
>
Anything can be taken to extremes. I've seen Ada code where the
proliferation of types & subtypes got so bad that you couldn't tell the
players without a scorecard. I've seen Ada code where the programmers
thought tasks were so cool, they ended up using them like they were
procedrues - to no advantage and with subsequent synchronization problems.
Obviously, someone sent these dudes off to a class that taught Ada & OOD/OOP
and they came back with half an understanding and lots of enthusiasm. The
first attempt at using just about any language may result in drastically bad
code because the newbie doesn't have the experience needed to make judgement
calls about the things that are rather subjective. (How many subtypes should
a program have? How many tasks should a program be broken down into? There
are no iron-clad rules. Like pornography, I can't write you a uniform legal
description, but I know it when I see it.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/