On Nov 23, 2011, at 10:35 AM, Nick Arnoeyts wrote:
> Yeah, I'm probably worrying prematurely.
> I'm very easily influenced by FUD and there are a lot of messages floating
> around that Python (and Ruby) are too slow for making games.
Since I started programming thirty years ago, and probably for the thirty years
before that, people have ALWAYS complained that "high level" languages are TOO
SLOW and USE TOO MUCH MEMORY.
Note that the definition of "high level" has changed over the years, but
suffice it to say, pretty much every single programming language has been
subjected to this complaint, from Python to Lisp, even FORTRAN.
The exception to the rule: C, because it was originally designed to be a very
thin layer on top of assembler. (C actually does add code, and slow down your
program, to do "fancy" things like make array references work like you think
they do.)
There's also this false economy -- if you write your code in fewer characters,
it'll run faster -- which eventually led to the "obfuscated C" contest. This is
entirely false -- unless your compiler is absolute crap, it will optimize your
programs just the same, whether they are 10 lines or 1.
Indeed, if you spend a lot of time reducing your code to the bare minimum, it
is more likely you will write incorrect code.
This is so prevalent that Kernighan and Plauger, who were some of the first
people to work on Unix and C, wrote a book called "The Elements of Programming
Style," where they repeatedly hammered the idea that "clever" code is a
terrible idea.
======> Knuth later said, "Premature Optimization is the root of all
evil." <======
To a certain extent, C++ also is not regarded as "big" or "slow," but that's
ONLY IF you give up the "good stuff" that makes it powerful: you can still have
object-oriented programming, but not certain powerful features of inheritance!
So in reality, for most code, C++ is not much faster.
The simple fact is this: For most high-level languages, you sacrifice some
percentage of your CPU and your memory space, and in return, YOU SHIP COMPLETE
PROGRAMS SOONER. You can find and fix bugs SOONER, and add new features
(because your users get to mess around and figure out what the REALLY want)
SOONER.
Making user wait while you screw around with your "clever" optimizations, then
deal with the bugs those introduced, is silly, especially because modern
computers are, actually, THOUSANDS of times faster than those of even 10 years
ago. And users don't care if your program takes 250 KB or 1MB, because you have
have many times that amount of images and sounds.
Now, of course, when you have a super-high-level language, like PyGame, and
it's running in an interpreted language like Python, you will run out of power
much sooner than you would in a language like C, especially on a "phone"
computer.
This, however, is no reason to stop using PyGame -- it's a reason to improve
PyGame. Improvements require a lot of technical knowledge, skill, and effort,
but they benefit MANY.
