Hmmm Should I Quit C++ To Learn Python?

[Svartalf]

Is this true even when you let C do most of the CPU intensive stuff by using pygame or pyglet or something like that?

Then you're writing things in BOTH languages- and moreover, you just LOST the advantage you might have had with Python unless you're trying to come up with an engine for someone to do somewhat simpler games easier. Serious. Pick one or the other.

I keep telling people that I've successfully used that model for scientific apps. I had about 2% C code, most of it Cython http://cython.org/. The rest was python and the interface and graphics were using Qt4. It was supposed to replace an old C++ and Qt3 app and mine actually performed better (probably because of qt4) and had less than a sixth of the LOC.



That was less because of Cython and more due to re-thinking and using Qt4... Trust me on that one. Also keep in mind that a game isn't a scientific app. It's a soft or hard real-time application in at least 1/3 of the cases we're talking about here.

QUOTE

The other choice for easily writing software is D, which has the performance of C/C++, but has garbage collection and a few other productivity enhancers (like insanely fast compilation).


That might not be a bad choice. But GC DOES inject it's own set of problems. Trust the old salt who has done quite a bit (25 years worth with over 17 differing programming languages...heh...yes, that long and that many...) on this- there's a reason that there's not a lot of Java based games and it's not all the JVM itself. The GC injects performance degredations into your app and at the oddest times. GC makes some tasks easier for the programmer to deal with at the expense of it pulling 5-10% (or more) away from your app's peak performance to clean house. Happens with Java. Happens with GCJ. Happens with D.

Each language choice has it's advantages and disadvantages and you've got to weigh what you're attempting to do with what the language DOES to you to give you results. There's things I'd do in D or GCJ. There's others that I will not do in anything other than C/C++ on game dev.

 

[Tastie]

well guys, you ALL have been a good help in deciding. After seeing these posts and racking my brain all day, i've decided to stick with C++ for the time being. But as soon as i have a good grasp on game programming, im going to start learning python also. I can't not learn one, so im going to wait a bit before diving into python!

you all were a great help in deciding!
Thanks :]

 

[dentrado]

Is this true even when you let C do most of the CPU intensive stuff by using pygame or pyglet or something like that?

Then you're writing things in BOTH languages- and moreover, you just LOST the advantage you might have had with Python unless you're trying to come up with an engine for someone to do somewhat simpler games easier. Serious. Pick one or the other.



"unless you're trying to come up with an engine for someone to do somewhat simpler games easier. "

Well exactly, thats what pygame and pyglet are (pyglet is kind of like SDL for python I've heard people say, and pygame is a wrapper around SDL).

I don't have to use both languages if i use python bindings to C/C++ code that somebody else made. Yes both languages are being used, but you only have to write code in one. There are several 3D engines, pyglet, pygame, physics engines etc. that uses C to do the hard work and python to bind stuff togheter. I don't see how using this model takes away the advantage of python, rather the opposite, takes away the disadvantage of the slow and unefficient code.

But yes this method is probably not good for getting optimal performance and writing games with really advanced graphics, but much better than using only python, and all pythongames I know of use this method.

 

[dithi]

That might not be a bad choice. But GC DOES inject it's own set of problems. Trust the old salt who has done quite a bit (25 years worth with over 17 differing programming languages...heh...yes, that long and that many...) on this- there's a reason that there's not a lot of Java based games and it's not all the JVM itself. The GC injects performance degredations into your app and at the oddest times. GC makes some tasks easier for the programmer to deal with at the expense of it pulling 5-10% (or more) away from your app's peak performance to clean house. Happens with Java. Happens with GCJ. Happens with D.

In D, you can halt and resume the GC whenever you want (e.g. disabling it when a cpu-critical part comes and enabling it again when there are enough computational resources but needs more ram, when loading, etc), you can also disable it entirely and reserve all by hand.

 

[DragonSpawn]

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.

 

[valhalla]

C++ will be better for game development, so if you find that after that book you are already able to write working programs with reasonable effort you can just stick with it; learning python afterward will still be useful, but will also probably be a matter of a couple of days.

However, python is an excellent choice as a first language because:
* simple things are _very_ simple to do (print "Hello World") and become harder only as they become conceptually harder
* it is very "clean": it is designed to encourage good programming practices
* most of what you learn with python will be useful when moving to other programming languages, the reverse is often not true
* it is powerful enough for lots of tasks, with performance being the only limit (of course, this _is_ a problem with lots of games, but it may come useful for other apps)
* even when you know and use other languages, python is still excellent for propotyping

Of course, if you want to develop games C++ remains the target, python is just a very useful step in between

I tried python on my own and it really is nicer to code in, but I'd never recommend it as a first language. basically because C is much more important (historically, and it's still widely used) and you need to know what's behind a language, know how it works and code with this in mind.

well, then you might as well learn some assembly, since it comes even earlier and is much closer to "what's behind": not that it is a bad thing, it does probably make you a better programmer, but it's definitely not what I would suggest to start with

QUOTE
C is easy enough to be your first language, little console apps are very easy to make in the first day and are sure to give the person the feeling involved in programming. and that's what's more important.



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

 

[Svartalf]

C++ will be better for game development, so if you find that after that book you are already able to write working programs with reasonable effort you can just stick with it; learning python afterward will still be useful, but will also probably be a matter of a couple of days.

Heh... Once you've learned one, if you've learned the right thinking when learning it, you can largely master most of them...

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.

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.

In D, you can halt and resume the GC whenever you want (e.g. disabling it when a cpu-critical part comes and enabling it again when there are enough computational resources but needs more ram, when loading, etc), you can also disable it entirely and reserve all by hand.

Uh, doesn't that undo the benefits of GC? If you're doing that, why not do it in C++?

(I knew that this was the case, that you can turn it off and manually handle it like one would in C/C++, but that was not what was being presented... They presented GC like it was a magic important thing, which it CAN be, but it's got a razor sharp double edge to it that anyone that touts it tends to either not realize or not warn people about...)

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.

If you want MY take on it, there's no good reason to NOT learn both. Just learn C++ first.

 

[sindbad]

In D, you can halt and resume the GC whenever you want (e.g. disabling it when a cpu-critical part comes and enabling it again when there are enough computational resources but needs more ram, when loading, etc), you can also disable it entirely and reserve all by hand.
Uh, doesn't that undo the benefits of GC? If you're doing that, why not do it in C++? (I knew that this was the case, that you can turn it off and manually handle it like one would in C/C++, but that was not what was being presented... They presented GC like it was a magic important thing, which it CAN be, but it's got a razor sharp double edge to it that anyone that touts it tends to either not realize or not warn people about...)

The point was that D overall is a much nicer and cleaner language and you can still afford to use the GC most of the time.

 

[Svartalf]

The point was that D overall is a much nicer and cleaner language and you can still afford to use the GC most of the time.

Heh... The main drawbacks would be that oftentimes you'll end up needing to build your own bindings for things because C++ is what everyone uses and D isn't actually used all that much right at the moment. I definitely won't tell someone to NOT use D- if they've got a proper tool match for what they're trying to do it's a good choice as any other. But to say it's magic...there's NO language that is "magic" or simplifies things THAT much. There's ALWAYS some sort of tradeoffs in everything you choose.

 

[sindbad]

It's not magic, of course. But there are enough tools and bindings that for most things it's better.

This is getting a bit offtopic

 

[Svartalf]

It's not magic, of course. But there are enough tools and bindings that for most things it's better.

Knowing a bit about the language, I'd hesitate to say "most" and would poffer "many" and suggest it as a possibility for some games on Pandora...

QUOTE

This is getting a bit offtopic



Indeed it is... This wasn't about "what pet language should he use" (Heh... With the right skillset, Forth would make rocking awesome games, but you don't see me proposing people actually USE it, do ya? That's MY pet language... ) afterall...

 

[sindbad]

It's not magic, of course. But there are enough tools and bindings that for most things it's better.
Knowing a bit about the language, I'd hesitate to say "most" and would poffer "many" and suggest it as a possibility for some games on Pandora...Could you elaborate on that? I'm quite curious, as I have used the language for some things.

 

[WizardStan]

In D, you can halt and resume the GC whenever you want (e.g. disabling it when a cpu-critical part comes and enabling it again when there are enough computational resources but needs more ram, when loading, etc), you can also disable it entirely and reserve all by hand.

Uh, doesn't that undo the benefits of GC? If you're doing that, why not do it in C++?

(I knew that this was the case, that you can turn it off and manually handle it like one would in C/C++, but that was not what was being presented... They presented GC like it was a magic important thing, which it CAN be, but it's got a razor sharp double edge to it that anyone that touts it tends to either not realize or not warn people about...)
The benefit of D in this regard is that you can turn of the GC, create your object, not have to worry about memory management at all, and when you as the programmer know it's safe, turn the GC back on, trigger it to run, and then turn it back off again so it doesn't interfere with the actual running of your program. Best of both worlds. Having cake and eating it, too. You strike down one edge of the proverbial sword so you don't accidentally cut yourself on the back swing. insert metaphor here.

 

[Svartalf]

Could you elaborate on that? I'm quite curious, as I have used the language for some things.

Not in detail. However "most" implies "silver bullet" from which I've seen I don't know HOW many languages that offered the same promises and failed to deliver. C# and Java being two of the more recent ones. D looks and acts like a C++ with some things "corrected" whether they really make things easier or not remains to be seen.

The remark was moderated from "most" to "many" because it IS a nice language that does bring things to the table- I think it's a hell of a lot more useful tool than C# or Java in the areas people seem to use it in. But, from 25 years of experience, if you're saying "most" for the global problem set you're missing something important somewhere.

The benefit of D in this regard is that you can turn of the GC, create your object, not have to worry about memory management at all, and when you as the programmer know it's safe, turn the GC back on, trigger it to run, and then turn it back off again so it doesn't interfere with the actual running of your program. Best of both worlds. Having cake and eating it, too. You strike down one edge of the proverbial sword so you don't accidentally cut yourself on the back swing. insert metaphor here.

Heh... You might be able to do that, you might not be. I've worked with systems where you plain flat couldn't KNOW when it was "safe" to turn it on or off. Work on some of that class of system for my day job. If you're turning it on and off, isn't that the same thing as doing things manually with C++ and smart pointers, etc.? Six of one, half dozen of another and it doesn't always lead to any better code or easier to maintain code. Now, I'm not ragging on D or saying it's not the answer for some games on this platform. What I'm trying to point out is that all the stuff you guys keep talking about is much the same thing that the Java and C# people touted in varying forms for some time now and they're not any better than the previous batch of the same stuff.

You're NOT going to find something that strikes down that proverbial edge of one sword without having a penalty of one or more forms present. Each thing you do is a tradeoff- whether it's speed, expressive power, or needing to be more careful in your coding.

 

[sindbad]

Could you elaborate on that? I'm quite curious, as I have used the language for some things.
Not in detail. However "most" implies "silver bullet" from which I've seen I don't know HOW many languages that offered the same promises and failed to deliver. C# and Java being two of the more recent ones. D looks and acts like a C++ with some things "corrected" whether they really make things easier or not remains to be seen.

The remark was moderated from "most" to "many" because it IS a nice language that does bring things to the table- I think it's a hell of a lot more useful tool than C# or Java in the areas people seem to use it in. But, from 25 years of experience, if you're saying "most" for the global problem set you're missing something important somewhere. I guess 'most' by itself is a bit too inclusive. 'Most uses of C++' would be more precise. Not a silver bullet, just a very good replacement.

C++ has evolved into a very large and inconsistent language that has very arcane semantics and a very complicated compiler. D attempts to fix that and mostly succeeds, depending on personal taste. It is in many ways easier to program than in Java, but has performance in the same range as C and C++ and you can, for things that really require extreme control and performance, program in a way similar to C.

 

[Svartalf]

I guess 'most' by itself is a bit too inclusive. 'Most uses of C++' would be more precise. Not a silver bullet, just a very good replacement.

Now, I might be convinced to agree with THAT particular remark.

QUOTE

C++ has evolved into a very large and inconsistent language that has very arcane semantics and a very complicated compiler. D attempts to fix that and mostly succeeds, depending on personal taste. It is in many ways easier to program than in Java, but has performance in the same range as C and C++ and you can, for things that really require extreme control and performance, program in a way similar to C.


I'd say the jury's still out on the "mostly succeeds", but I would be convinced to consider doing new work with it for some things- what tinkerings I've done with it seem to allow for cleaner expression of C++ concepts. Unfortunately for moi, I'm stuck dealing with other people's code. I don't think re-working any of the LGP titles I've access to the source code to from C++ to D (though that MIGHT fix a few problems on ONE of those titles... ) is a good use of my time.

 

[sindbad]

Unfortunately for moi, I'm stuck dealing with other people's code. I don't think re-working any of the LGP titles I've access to the source code to from C++ to D (though that MIGHT fix a few problems on ONE of those titles... ) is a good use of my time.
Of course, rewriting stuff is annoying and time-consuming. I would say though that it's interesting how straightforward it is to translate Java code to D. There are a few projects doing automatic translation and one of them (tioport I think, with the dejavu classpath) can run non-trivial programs.

Btw, D 2.0 has some facilities to call C++ code in case you missed it, that could be of some help to you.

 

[VRAndy]

QUOTE
Hmmm Should I Quit C++ To Learn Python?
No.

 

[Tastie]

QUOTE
Hmmm Should I Quit C++ To Learn Python?
No.

lol, that seemed to be the consensus, and what i decided on

 

[laurens]

QUOTE
Hmmm Should I Quit C++ To Learn Python?
No.

lol, that seemed to be the consensus, and what i decided on

I know both C/C++ and python quite well, and I would actually recommend you'd use python (using pygame/pyglet), because that can give you results much quicker;

Since this is the first game you are going to make, it will probably start out simple. Using python, I find that I can very quickly prototype/start my game, and find that python is for many type of (simple) games, fast enough. Using C/C++ with for example SDL gets you something relatively quickly too, but you end up typing a lot of support code which you simply don't need to do in Python.

Once you get the hang of it and ARE running into speed problems, you can always move up to c/c++. By then you've had some practice with the programming principles which are roughly the same in the easier-to-use python, while not having to deal with some nastyness of C/C++. The skills you'll learn when learning python will prove valuable when learning C/C++/Java or any other programming language.

Recommended reading: http://diveintopython.org and http://pygame.org; pygame even has an intro for python, albeit not that in-depth: http://rene.f0o.com/mywiki/LectureTwo