Hmmm Should I Quit C++ To Learn Python?

[Rockthesmurf]

My opinion is, at this moment in time, C/C++ is the best language for making games. For people just getting into programming games an easy to use set of libraries is what is needed to make the experience a lot more fun (and make it feel more like what is often thought of as the 'Python' way). Python is great in as far as there are loads of modules built in to it for performing all sorts of tasks, and there are 1000's more for doing just about everything else - but you'll normally find there are similiar alternatives for C++ too.

Just my opinion!

Steve

 

[Eniko]

So much hate for C#. It's a really great language for a lot of things, so I don't understand that sentiment. The biggest thing it has going against it is portability, or lack thereof, IMHO.

On the topic of garbage collectors and how they "have their own problems" this is something I see programmers who are proficient at non-GC languages saying a lot. The thing is, of course you can't just build GC into a language/virtual machine/whatnot and expect to never have to do anything related to garbage collection in your code ever again.

Like if I were to use C# and XNA (XNA is such a lovely library, why can't Python libraries take a hint from XNA?) to make a game with a lot of spawning/destroyable enemies I'd eventually have to deal with the fact that after a while the GC will kick in, remove the objects from memory all at the same time, and delay a single frame of my game for much longer than desirable.

Of course, what people who make this argument seem to forget is just that because you don't have to manually allocate and deallocate memory doesn't mean you can't. And if given the choice between managing all of it, or only some, I will always go for some. Especially since the GC is insurance against hard to track down memory leaks in non-crucial parts of my code.

/rant

EDIT: Now if you want to make a proper argument against automatic garbage collection you should be making the point that garbage collectors like CPython's that use reference counting have the inherent danger of cyclical references which - if you're careless - can be almost as hard to track down in a complex project as a good old fashioned memory leak. Note though that other GCs like the one in the .NET framework don't suffer this same flaw.

 

[sindbad]

/rant

EDIT: Now if you want to make a proper argument against automatic garbage collection you should be making the point that garbage collectors like CPython's that use reference counting have the inherent danger of cyclical references which - if you're careless - can be almost as hard to track down in a complex project as a good old fashioned memory leak. Note though that other GCs like the one in the .NET framework don't suffer this same flaw.
The CPython GC uses reference counting with added cyclic reference detection. In fact, reference counting is more predictable than a more 'proper' GCs and is sometimes used in real time systems, so from this point of view CPython is a pretty good choice.

The hate against C# is the inevitable collateral damage for the very natural hate towards Java. C# is a bit nicer than Java, but still much more annoying to program in than Python or Ruby. After you start exploiting dynamic features a lot and you write idiomatic code, even Javascript seems needlessly restrictive.

 

[Eniko]

The CPython GC uses reference counting with added cyclic reference detection

It has cyclical reference detection, really? I wonder how I managed to miss that somehow... I could've sworn I had a problem with cyclical references and memory not being freed using CPython at some point in the past.

 

[phrosty]

Though I have written a few quick scripts in Python, I do not know it well enough to have an opinion of it. But I do know C++ very well, so I will give some thoughts on it. One thing I will say - use the right tool for the job. C++ might not be it, and Python might not be it. Look at your requirements and find out what the language has to offer to make it done easier.

C++ is tricky. First, it requires patience. It is very complex and can take three or four years to become really good at, and double that to master. Second, it requires discipline. It gives you complete control, but that means it also lets you blow your leg off if you so choose -- and that if you want you can create some very unwieldy code that will make others either look at you with awe or despise you.

If you have those traits, you will love it and might find it the best swiss army knife you could have.

In C++, resources are automatically reclaimed when they go out of scope. Garbage collection doesn't make sense for it. I do not know if it's an inherent problem of garbage collection or merely a problem with the way I've always seen it implemented, but it also precludes the use of arenas or pools which are very important in low-memory/high-performance situations (like the Panda, and most non-trivial games I've seen the code for).

 

[Svartalf]

Though I have written a few quick scripts in Python, I do not know it well enough to have an opinion of it. But I do know C++ very well, so I will give some thoughts on it. One thing I will say - use the right tool for the job. C++ might not be it, and Python might not be it. Look at your requirements and find out what the language has to offer to make it done easier.

That's about the best remark that one could make on the whole discussion- couldn't have put it better myself, really.

There's a whole host of games you can do in Python. There's another batch of things that only make sense if they're coded in D or C++.

QUOTE

C++ is tricky. First, it requires patience. It is very complex and can take three or four years to become really good at, and double that to master. Second, it requires discipline. It gives you complete control, but that means it also lets you blow your leg off if you so choose -- and that if you want you can create some very unwieldy code that will make others either look at you with awe or despise you.



It's when they start doing Template Metaprogramming that it gets' that sort of "fun"- and it can go either way or you could end up doing both. (Awe in that they could come up with the evil crap, disgust that they did it in a production system and now I've got to maintain it...sigh... I've worked with people like that at my previous day job. )

QUOTE

In C++, resources are automatically reclaimed when they go out of scope. Garbage collection doesn't make sense for it. I do not know if it's an inherent problem of garbage collection or merely a problem with the way I've always seen it implemented, but it also precludes the use of arenas or pools which are very important in low-memory/high-performance situations (like the Panda, and most non-trivial games I've seen the code for).


Actually, you CAN have arenas or pools because with C++ you can control when a resource goes out of scope.

 

[Squidge]

In C++, resources are automatically reclaimed when they go out of scope. Garbage collection doesn't make
Only if the resource has an explicit or implicit destructor, otherwise only the reference is reclaimed, and the resource can sit around in memory for the entire duration of the program, or until you decide to delete them yourself (assuming you still have a reference to them that didn't get out of scope beforehand).

 

[Svartalf]

In C++, resources are automatically reclaimed when they go out of scope. Garbage collection doesn't make
Only if the resource has an explicit or implicit destructor, otherwise only the reference is reclaimed, and the resource can sit around in memory for the entire duration of the program, or until you decide to delete them yourself (assuming you still have a reference to them that didn't get out of scope beforehand).

That's why I like smart pointers... If you use 'em right, they bring you all the good things about GC with none of the trawling the resource allocations looking for something no longer in use.

 

[valhalla]

QUOTE

I disagree: C may be easy enough in that it is described in a small book, but to start writing even simple console apps you need to know almost everything in that book, and that prevents you from learning by trying as you go

also, to start programming in C you have to learn lots of C-specific quirks that won't be of any use when moving to any other language

Excuse me. You'll find that your argument that you'll learn "Foo" specific quirks that won't be of any use when moving to any other language in Python, Ruby, Perl, Java, etc. applies to that language Serious.


of course Foo specific quirks are of no use when moving to Bar; my experience is that when using python as a learning tool you don't need to know as many python quirks as you need c/c++ quirks to learn those

so, if you want to learn N programming languages it makes perfectly sense to start with python, learn good programming practices, and then move to the other languages

QUOTE

Moreover, your remarks are wrong and conflicting... You just told the boy that C++ was a good choice. The bulk of the narfy tricks in C apply to C++ as well- because C++ is OO C for all intents and purposes.



yes, for writing games C++ is a good choice, so he will have to learn it sooner or later; if he already got to the point where he can use it to write working nontrivial stuff, he can just stick with it, if he - or anybody else reading this thread - is still having problems with the quirks of C++, learning python first and C++ later is a great help

QUOTE

No reason you can't learn both
But I would stick to C++ first, since it is a bit trickier to learn. After that Python wont take more than a week or two to become comfortable with.
Worked for me anyway.

And there's a second person chiming in with the sensible remark.


that's exactly the problem with C++: it is trickier to learn, and the usual didactical method is to start with easier things and then progress to harder ones

 

[kloplop321]

python doesn't run too fast on my pentium 2 laptop in linux, If you are making a game, find out what your limits are, and if you plan to expand, I suggest staying with C++

 

[Eniko]

python doesn't run too fast on my pentium 2 laptop in linux, If you are making a game, find out what your limits are, and if you plan to expand, I suggest staying with C++

Or create a prototype entirely in Python and if it's too slow profile the code and use C for the bottlenecks using Pyrex.

 

[Capn_Fish]

Let me just say that on the Zaurus with PdaXrom, the Wi-Fi config app was coded in Python, and took something like 10 seconds to load. An app that did the same thing coded in C++ with FLTK took less than a second.

Python is completely the wrong language to use for anything that you need even a small amount of performance for (which, IMO, is just about everything). Stay with C++.

Let me just say that on the Zaurus with PdaXrom, the Wi-Fi config app was coded in Python, and took something like 10 seconds to load. An app that did the same thing coded in C++ with FLTK took less than a second.

Python is completely the wrong language to use for anything that you need even a small amount of performance for (which, IMO, is just about everything). Stay with C++.

 

[sindbad]

Let me just say that on the Zaurus with PdaXrom, the Wi-Fi config app was coded in Python, and took something like 10 seconds to load. An app that did the same thing coded in C++ with FLTK took less than a second.

Python is completely the wrong language to use for anything that you need even a small amount of performance for (which, IMO, is just about everything). Stay with C++.
That Python app must have been remarkably badly coded. Also, you cannot generalize from one example.

 

[lardman]

Python start-up times are a know issue, along with the fact that if everything is import'ed at the start of the file, all the imports are done there and then, again slowing down the startup (i.e. time until someone sees a GUI).

Some of this can be sorted by only importing when functions are needed, or by afaiu some work being done to support lazy importing.

 

[Capn_Fish]

Let me just say that on the Zaurus with PdaXrom, the Wi-Fi config app was coded in Python, and took something like 10 seconds to load. An app that did the same thing coded in C++ with FLTK took less than a second.

Python is completely the wrong language to use for anything that you need even a small amount of performance for (which, IMO, is just about everything). Stay with C++.
That Python app must have been remarkably badly coded. Also, you cannot generalize from one example.

I realize that, my apologies.

Still, I believe Python's a poor choice for game creation (Unless I'm incorrect in my impression that Python is relatively slow (compared to C++) and memory-hungry (once again, compared to C++).

 

[Eniko]

Still, I believe Python's a poor choice for game creation (Unless I'm incorrect in my impression that Python is relatively slow (compared to C++) and memory-hungry (once again, compared to C++).

That's a rather simplistic criteria for establishing whether a language is a good choice for game creation. If you're only a single developer working on a game "speed of development" is a rather important criteria too. If with Python you can finish a game that's inefficient while with C++ you can create an unfinished game that is efficient I know which one I would pick.

Furthermore most independent games aren't incredibly complex so they don't even need to optimize for speed or memory usage, which means going with C++ is basically the same as spending time optimizing something that doesn't need it. Most of the really intensive parts (like blitting) aren't done in native Python code anyway.

 

[dithi]

python doesn't run too fast on my pentium 2 laptop in linux, If you are making a game, find out what your limits are, and if you plan to expand, I suggest staying with C++

Or create a prototype entirely in Python and if it's too slow profile the code and use C for the bottlenecks using Pyrex.


Oh YEAH!! Why didn't I hear about this before????!

I've just made an extension library with Cython, interfacing with an external C lib and it's GREAT!!
Mixing C and Python never have been so easy. Much better than ctypes.

 

[Capn_Fish]

Still, I believe Python's a poor choice for game creation (Unless I'm incorrect in my impression that Python is relatively slow (compared to C++) and memory-hungry (once again, compared to C++).

That's a rather simplistic criteria for establishing whether a language is a good choice for game creation. If you're only a single developer working on a game "speed of development" is a rather important criteria too. If with Python you can finish a game that's inefficient while with C++ you can create an unfinished game that is efficient I know which one I would pick.

Furthermore most independent games aren't incredibly complex so they don't even need to optimize for speed or memory usage, which means going with C++ is basically the same as spending time optimizing something that doesn't need it. Most of the really intensive parts (like blitting) aren't done in native Python code anyway.

I guess we're all entitled to our own opinions. I prefer to work on something that is optimized and quite possibly never finish it rather then do something that works slowly. If you don't agree, that's fine by me.

I'm just happy that people are trying to learn to code!

 

[Eniko]

I guess we're all entitled to our own opinions. I prefer to work on something that is optimized and quite possibly never finish it rather then do something that works slowly. If you don't agree, that's fine by me.

I'm just happy that people are trying to learn to code!

For the record, I have nothing against preferring to do it that way. I'm just afraid to let a statement like "I believe Python's a poor choice for game creation" stand unchallenged. People might read it and take it as fact, rather than a personal preference, and get the wrong idea about Python.

And yes, people learning to code is always a good thing.

 

[BenTolputt]

I think, when considering the language to develop a game in, there are several things to remember.

1. The Game: If you are developing a simple game, putting together the C/C++ framework (along with the compilation issues that brings) might be way too much effort. I can see alot of "casual games" being developed using a scripting language only (Python being one of the more prevalent).
   
   On the other hand, larger game projects need to use C/C++ in order to implement features that would simply chew up & spit out a scripting language when it comes to performance & memory requirements. Putting together collision & physics code in Python is going to be a waste of time, C/C++ code is going to be much more efficient for this purpose. Which leads into...
2. The Libraries: Depending on the libraries you intend to use, some games are faster/easier to put together in the scripting language. In these cases, it is possible the best use of your time is to put together scripting "glue" that connects the relevant libraries to make you game.
   
   As an example, I would never think of writing a 3D/video, audio, or physics engine in Python. On the other hand, there are libraries (such as Panda3D, PyAudio, & PyODE) already doing these things that would allow me to simply write the code implementing my game and leaving the performance characteristics of these components to better developers than myself.
3. The Platform: Much as I hate to say it, the platform is a very relevant consideration on this forum and, honestly, this weighs against Python on the Pandora. Python is a relatively heavy scripting language in terms of both memory usage and performance. The more code you are dedicating to Python, the more you need to consider the limitations of the platform. Looking at the "Computer Language Shootout", Python is pretty bad in comparison to other languages, native compiled or otherwise (between 13-17x slower than C/C++). On a limited system like Pandora, the more you rely on Python for the "core engine" (as opposed to game logic & glue only) - the less likely your game will perform reasonably on the handheld.
   
4. The Team: Depending on the team you have and/or are likely to attract - sometimes scripting is the only choice you've got. A couple of geeky artists are not likely to put together a C/C++ engine, but they would be able to crank out the art & game design needed to actually get the game off the ground.
   
   I, for example, am a C/C++ programmer who has been seriously pondering Python/Lua as the language of choice for my projects as I don't have said artists. I cannot dedicate the time to both decent artwork AND a decent C/C++ engine. I can probably do one (I'm not a bad 3D artist, though by no means "great" & likely not very far into "good"), but it's a trade off.

One other thing I'd like to add (as it is relevant to people reading this thread, if not directly the subject of it), is that one needs to look carefully at the limitations of the language/libraries one is using. It may be easy to get a test framework up and running in almost any scripting language. Things become harder when you push beyond the test framework / tech demo stage though. You don't write multi-threaded servers in Python and expect performance; just as "plug & play" libraries like Irrlicht, Blender Game Engine, & Panda3D become harder to optimise the more complex the game becomes.

--Ben