Re: Game announcements on LGDC

[Bert Peers <rat@larian.com>]

Jeff Read wrote:

> > to give negative comments in a LGDC submission review.  Obviously
> > I'd disagree, pointing out that this is exactly a plus, making it as readable
> > as a newspaper.
> [snip, moved to bottom]
> As for long function names, that's a sort of COBOL mentality, that code
> should be "just as easy to read as ordinary text", and adding lots of
> verbosity is a means to this end. A seasoned COBOL programmer, for
> instance, would suggest that I replace the variable STARTX with
> STARTING-X-POSITION-OF-SPRITE. Ack. Well, it doesn't work that way
> because reading computer code, particularly well-structured code,
> requires a different cognitive process than reading a newspaper. The
> ordinary rules of readability don't necessarily apply. Using shorter
> mnemonics is actually preferable IMHO because it a) prevents my fingers
> from wearing down to stubs and b) produces cleaner code that's easier to
> read from a clutter standpoint. Parsing entire phrases isn't something I
> want to do when I'm looking at the name of a function or variable.
> Hence, my functions tend to be concise: MoveSprite, ChangeSpriteShape,
> SetSpriteMotion, etc. :)

Awwwwwwwww yeah, this is on the brink of trying to tell me I don't know
how to code, but I'll swallow and reply, after all I ignited the fire ;)
I actually agree with you.  When I said "read like a newspaper" I didn't
mean to say "read like news".  A newspaper you read to get the news,
code you read to get the flow of it.  Obviously, they're different processes,
and I hope my comment, which I indeed borrowed from the Cobol community,
doesn't suggest that I fully support their views which take the analogy to the
extreme.  (As for STARTING-X-POSITION-OF-SPRITE, this is a clear
example of the deep roots functional thinking has in the Cobol community.
If it's the starting position of something, it should be a property of that
something,
in casu some Sprite object).
  See, if I would only mean "longer names" with high verbosity you would
be right in attacking me, aside from the STARTING-... example.  But high
verbosity is more than that.  It means decorating complicated while loops
with pre and postconditions and invariants.  It means documenting interfaces
with algebraic definitions where necessary.  It means writing
"if (... && ...) /* ! And then ! */ {}" to be extra clear when the sequence
of tests is critical.

  It means, except for the rulebreaking odd case, only using short variable names
for variables that serve as a counter or a simple loop breaking flag; not variables
who's semantics go beyond this.

  Yes, the reading of code is a different realm than the reading of a newspaper;
hence, please apply the metaphor in the correct way.  Which
are the easiest to digest, the regular articles or the "wanted : fem. br. 18yr.liv.
nr. LA gd l hby sprt movs msc" :)  Is a political editorial easier to read when the
name of the politicians are repeated everytime they're needed,
instead of simply being referred to as "him, her" or worse yet "X" and "Y" :^)
(lol)
  I think there is this line of complexity, that starts out with assembly
programming
and adds more and more formality, until you end up with specification-generated
listings (beyond 4GL -- rare).  If it weren't for efficiency and the complexity of
formally defining a problem, rather than "just" coding a solution, we'd all be
trying
to move up the line all the time, but to be realistic we get stuck somewhere
halfway.  Then, looking forward you see more advanced stuff which you can't
use because of the costs, but which you can mimic or use in a reduced form.
Doing that the wrong way causes the Cobol symptoms.  Looking backward you
see code that is probably more efficient, but expresses so much less than what
you can write at "your" level, that it seems a zillion times more complex to
understand, extend, in short maintain.
  Shit, did that make any sense actually ?  Anyone ? :)

>Advanced IDE? *smirk* Visual C++ is aimed less at developing code and
>more at gluing and duct-taping together Microsoft-authored components.
>It's the non-programmer's programmer's tool. Plus it's bloated and costs
>too much money. :) Give me XEmacs any day of the week. But enough of
>this flamage.

My boss bought it, so I don't mind if it's expensive :)  Yes, it's awfully
slow, as I experienced back when I had a P133 with 32 megs; right now
I have a P2/300 w 256Mb (win98 only using a fraction of it, but still) so
I don't care ;)

> >   Oh well.  This could probably go on forever :)  I'll just say that I support
> > the idea of barring Bad Code from the site, but I want to stay as far away
> > as possible from the actual labeling of submissions.
> Hey, their code might do something cool, even if their style is poor.
> For example, there is a relativistic raytracer out there that's coded as
> one big .CPP file greater than 300K in size. I don't think we should bar
> the announcement of something interesting or useful if someone feels the
> author didn't comment it properly (this is kinda one of my sins :)) or
> the function names aren't descriptive enough.

Voila.  The idea of barring code is not unanymously cheered upon,
and nobody has come forward to take the responsibility of being the
one to judge what's cool and what's not.

So what do we do ?

Bert