RE: [stella] OT: Programming, CS theory

Subject: RE: [stella] OT: Programming, CS theory
From: "Kennehan, Richard" <Richard_Kennehan@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 25 Oct 2001 17:11:08 -0500
>I'm also constantly amazed at how many people, especially those with
>CS degrees, know nothing about data structures, algorithms, or their
>effective application. (lots of hobbyist programmers tend to ignore
>the importance of CS theory, too...)

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

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!

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

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?

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

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

Do you have some specific examples of CS theory that you see ignored, but
shouldn't be ignored, and actually WORKS in practice?

Archives (includes files) at
Unsub & more at

Current Thread