Re: [stella] OT: Programming, CS theory

Subject: Re: [stella] OT: Programming, CS theory
From: AutismUK@xxxxxxx
Date: Fri, 26 Oct 2001 07:49:42 EDT
In a message dated 25/10/01 23:14:07 GMT Daylight Time, Richard_Kennehan@xxxxxxxxxxxxxxxxxxxx writes:

I have a CS degree, and I have found a great deal of difference between what
works "in theory", and what works in practice:

THEORY: Recursion is great!
PRACTICE: Recursion wastes memory and assumes that the compiler's garbage
collector is 100% flawless, which is rarely the case

True, however it *can* be a useful solution. Recursion is more about getting
people to think differently about programming. At Uni, I can still remember some
people's attempts at LISP programming., which were done as straight translations
from Pascal.

The Garbage collection is irrelevant in recursion, surely ? There isn't any
"garbage" to collect, just a series of frames on the stack.

THEORY: Avoid the use of global variables, only use local variables!
PRACTICE: Using locals results in having to pass parameters by reference,
and uses more stack space, and results in more variable declarations, thus
increasing possibilities of incorrectly declared variables.  In fact, most
game programming books tell you to use globals and avoid locals!

This is more about design theory, avoiding the creation of spaghetti code. It's
more about thinking about when to use globals, rather than just using them
all the time as a BASIC programmer might do. The amount of stack space used
is minimal (a pointer !). The advantages come when you try and change code
and/or generalise it ; like you want two sets of the same global variables.

THEORY: Never use GOTO statements!
PRACTICE: Avoiding GOTOs sometimes results in nested IF statements that are
200 lines long, which are a pain to debug

Which suggests you might be better off redesigning the whole thing. Commercial
or theoretical doesn't matter, you ought to be shot for 200 line nested If statements.

THEORY: Never learn to program in BASIC, it ruins your brain and prevents
you from learning how to program "properly"
PRACTICE: Nobody can seem to define what "properly" is, and what about
Visual Basic, which is a complete 4GL application development environment?

Visual Basic is not much cop IMO, beyond its basic scope as a Win/database
front end.

You can program properly in BASIC, just (say) Pascal makes it harder not to.

THEORY: Inheritance is great, make one change, and it cascades down to its
child members!
PRACTICE: Sometimes the child becomes so specialized its better off on its
own, and trying to "divorce" a child from its parents most often results in
the entire child object having to be re-created from scratch...and in actual
developmental practice, Inheritance is only marginally better than

Hardly. Like anything else, it's about understanding when to use it and when not to.

THEORY: You can combine several statements together, like
for(++i;i<lseek(fp)) {i+=lseek(fp+i)};
PRACTICE: This makes it impossible for other programmers to decipher your
work, and causes the compiler to generate code which is not easily
digestible by the CPU's execution units.  Most game programming books tell
you to program in a RISC-like manner to maximize the CPU instruction
execution pipelines

Any CS course that recommends you write code like your C fragment should be
closed, [notwithstanding the fact that it's wrong :)]

I don't even quite grasp what the last bit means ; program in a "RISC like manner"
???? Using things like the ++ and += construct should make life easier for the
compiler if anything ; but many compilers will be able to work it out.

As for pipelining, the compiler will do a better job of that anyway, unless you hand
code it. And in 99.9% of code it doesn't matter anyway.

Current Thread