Re: [stella] OT: Programming, CS theory

[AutismUK@xxxxxxx]

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
> copy-and-paste


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.