Python in game development?

[Gerry Quinn]

In article <8ohm5u$lha$1 at fremont.ohsu.edu>, "Jason McDermott" <mcdermoj at ohsu.edu> wrote:
>
>> In article <T1Ze5.9877$r4.5093 at news.indigo.ie>,
>> Gerry Quinn <gerryq at indigo.ie> wrote:
>>>In article <8lh588$oti$3 at news.fsu.edu>, Ronald Steedman
>>><steedman at quake.cs.fsu.edu> wrote:
>>>> Imagine how an intepreter would help. Try one thing IMMEDIATELY SEE THE
>>>> RESULT... try another thing IMMEDIATELY SEE THE RESULT... then you only
>>>> compile the application when you're finished and want a faster program.
>>>
>>>If I were your boss I would make sure you had no access to an
>>>interpreter!  I would even slow down your compilation by giving you an
>>>older machine ;-)
>>>
>>>Changing things at random and hoping the problem goes away is not the
>>>way to fix bugs.
>>
>
>I would contend that this is the essence of good programming, just as its
>the essence of good science- look at the code (to borrow from genetics, the
>genotype), propose a hypothesis, test the hypothesis by changing the code,
>examine the results of the change (the phenotype), repeat ad nauseum until
>the bug(s) are fixed. While its true that random alterations in your code
>made willy-nilly are likely to be detrimental- modifications designed to
>test a hypothesis are what debugging (the fun part of programming :) is all
>about.
>

As eep2 would put it: "Evolve, champ!".  We are no longer doomed to 
blindly groping in the dark - the evolution of ideas can be Lamarkian as 
easily as Darwinian.

Okay, the bugs can sometimes be located by test examples, 
single-stepping, all manner of things.  But really fixing them means 
understanding what went wrong.  I always have a really bad feeling about 
code that works when I don't really know why it works...

Gerry Quinn                                   
-- 
http://bindweed.com
Puzzle / Strategy Games and Kaleidoscope for Windows
Download evaluation versions free, no time limits
New: Unique 2-player strategy game "Zen"