Python in game development?

[Jon Kirwan]

On 24 Jul 2000 14:08:25 -0400, David Bolen <db3l at fitlinxx.com> wrote:

>gerryq at indigo.ie (Gerry Quinn) writes:
>
>> In article <8lh588$oti$3 at news.fsu.edu>, Ronald Steedman <steedman at quake.cs.fsu.edu> wrote:
>> > A full compile of a complex software package can often take 30 seconds or
>> > more. That can be frustrating when you're trying to find and remove bugs.
>> > You try one thing, wait 30 seconds, try another thing, wait 30 seconds...
>> >
>> > 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.
>
>Where in the above did he say "random" and "hope"?  Being able to
>iteratively and interactively make changes hardly has to impact the
>methodology used in arriving at those changes to be made.
>
>Or are you saying that the use of a compiler would remove the need to
>ever iterate more than once on a bug fix?  I'm not sure I'd agree :-)

I'm guessing at Gerry's meaning here, drawing from my own
observations, but...

Perhaps he meant to point out the lack of discipline that a
prototyping language may often encourage.  Folks start "hacking" their
code into what appears to be the right behavior rather than designing
it in, from careful thought.  They may instead wait until the
interpreter slaps up an error dialogue on some line and then just hack
in an 'IF' to "cover (fix) it."

Perhaps "random" and "hope" were too strong of words.  But the gist
may have been that he'd like to encourage the kind of mental skills
developed, that better happen when you are coding "on a high-wire and
without a net."  I use a debugger rarely and sporadically -- perhaps
twice a year, on average -- usually to clear up an ambiguity not
entirely obvious from the instruction documentation.

Debuggers and interpreters are often (but not always) used chronically
as crutches to get around in everyday life, rather than the occasional
solution to an acute problem.  Mental growth languishes and withers
with such poor exercise.

Jon