Comments on: And now you think I should be using C! I'm sorry, I can't resist the urge to point out that the record these days is 63.000+ concurrent players running that python code :P Cheers, the Eve Squad. I’m sorry, I can’t resist the urge to point out that the record these days is 63.000+ concurrent players running that python code :P Cheers, the Eve Squad.

]]>
By: TomF/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-950 TomF Wed, 23 Feb 2011 23:30:21 +0000 I don't see why C/C++ can't be a perfectly reasonable "scripting language". In Python you might write: def OnPlayerInteract (player, item): player.AddToInventory(item) but would anyone really object to writing the same in C? void OnPlayerInteract (Player player, Item item) { player.AddToInventory(item); } Sure, there are a few more keystrokes, but we now have static type checking, a full featured debugger that can step into the game code, and all the advantages of optimized native code. There is no reason for these C scripts to require a 10-minute compile. Let's just compile them into small DLLs. We can link them with a very minimal C-runtime library which would allow all sorts of useful restrictions or additional features, e.g.: * no support for dynamic memory allocation -OR- * an API to provide a specific memory allocator Since they are now DLLs, we can even unload and reload them without restarting the game. I'm going to give this a shot in my hobby project. I suspect I can get a big iteration win by swapping out small blocks of logic without restarting the application. I don’t see why C/C++ can’t be a perfectly reasonable “scripting language”. In Python you might write:

def OnPlayerInteract (player, item):
player.AddToInventory(item)

but would anyone really object to writing the same in C?

void OnPlayerInteract (Player player, Item item) {
player.AddToInventory(item);
}

Sure, there are a few more keystrokes, but we now have static type checking, a full featured debugger that can step into the game code, and all the advantages of optimized native code.

There is no reason for these C scripts to require a 10-minute compile. Let’s just compile them into small DLLs. We can link them with a very minimal C-runtime library which would allow all sorts of useful restrictions or additional features, e.g.:

* no support for dynamic memory allocation -OR-
* an API to provide a specific memory allocator

Since they are now DLLs, we can even unload and reload them without restarting the game.

I’m going to give this a shot in my hobby project. I suspect I can get a big iteration win by swapping out small blocks of logic without restarting the application.

]]>
By: David Evans/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-925 David Evans Tue, 22 Feb 2011 08:48:48 +0000 std::vector vec(0); Ah, see? It should have been 10 instead of 0! Now, if only you had been using a real language, like... okay I am kidding. Great comment by the way, but don't take language wars too seriously, it's all tongue-in-cheek. std::vector vec(0);

Ah, see? It should have been 10 instead of 0! Now, if only you had been using a real language, like… okay I am kidding.

Great comment by the way, but don’t take language wars too seriously, it’s all tongue-in-cheek.

]]>
By: jalf/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-901 jalf Mon, 21 Feb 2011 11:48:21 +0000 auto result = somearray[i]; // works
auto result = somearray[s]; // compile error

What a shame Python can’t do the same, eh? Python would happily allow me to write code that *relies* on a variable having a certain type, but without any way to enforce it or verify that the variable will actually have that type.

And you tout that as an advantage? The ability to write code containing trivial, undetected errors?

I’m all for type inference, but apparently you only want to go halfway? Let the language figure out the type of a variable, *and then not make use of it*. I want it to go all the way, automatically infer the type of a variable, and then use that information to verify the *rest* of my code. This is 2011, and as you point out, we’ve got ridiculously fast computers. Why can’t *they* verify my code for me? Why would I have to write a unit test for every goddamn thing, when compilers have been able to perform type checking for decades, and are only getting better at it?

Oh, and code that’ll fit in a tweet?


std::vector vec(0);
std::generate(vec.begin(), vec.end(), std::default_random_engine());
std::sort(vec.begin(), vec.end();

does the same thing as yours (130 chars, so hey, we can even fit a silly hash tag into the tweet along with it!)

So, let me ask you: is the answer to all the C++-snobbery out there really to counter it with equal amounts of Python-snobbery? Does the widespread ignorance/fear of “scripting languages” really warrant equal amounts of fear and ignorance of C++ and compiled/statically typed languages?

What a depressing prospect.

I haven’t written a memory leak in C++ for at least the last 4 years. It’s just not difficult, *if you know the language, and if you don’t treat it like C*. My stack isn’t corrupted, and the bug from last week isn’t there today. Oh, and relying on the compiler to type-check my code saves me a lot of trouble too. Think of all the unit tests I don’t need to write.

It’s so much easier to say “hey look, if I write terrible code in language X, it’s buggy, and it’s a pain to fix, whereas if I write good code in language Y, everything just works”.

This whole “my language is better than your language” is a bit passé, isn’t it?

C++ is a deeply flawed language, sure. But it also has advantages that Python can’t counter. And even if we dismiss C++, there are other languages which, according to you would be “not real”, but which offer powerful type checking, guaranteed safety against memory leaks and stack/heap corruption, as well as state-of-the-art type inference, *as well as* fast compile times and excellent runtime performance.

But I suppose game programmers are more interested in sniping at those who prefer a different language… Python programmers on this side, C programmers on that, and get ready for some serious mud-flinging. Oh, and C++ programmers in between where they can be hit by both sides, of course.

In short, *of course* we need to treat script code as real code, and scripting languages as real languages. I can’t imagine a single reason why we shouldn’t.

But I don’t quite see how that leads to the implication that *no other language can be a real language, and code written in C++ isn’t “real code”.*.

I don’t know about you, but I don’t want to replace the games industry’s obsession with C/C++ with an equally restrictive obsession with Python.

Is it so unrealistic to hope that one day, we might be willing to accept that there might be more than one language that’s worth using? That it’s not a choice of “either or”. That C++ has advantages over Python, just like Python has advantages over C++, and entirely different languages have advantages over both? That there’s no such thing as “not a real programming language”?

]]>
By: Alia/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-894 Alia Sun, 20 Feb 2011 18:29:37 +0000 So way back in 2000 I worked on a (simple) PC title that used Java as the game language and C++ for the heavy lifting. It worked relatively well. I'm more a systems programmer, so from my point of view, here's why I think there's resistance to languages like Lua et al: 1. The lack of many JIT options on console. The consoles basically prevent you from shipping a JIT, which is fine (I can ship statically compiled code). The problem is this seems to mean not too many people are particularly interested in providing a JIT for development purposes. Mono seems to be supplying a IL environment for PS3/360 (anyone have experience with this), but information on it seems thin. You're other option is interpreting the bytecode (slow), or porting an existing JIT to the platform (which I'm sure people have done, but due to the funky way console NDAs are, it's very difficult to share such work). Maybe there are some more alternatives today since I last looked at this. You could just statically compile, for sure, but then you've got the same iteration time problems as with C++ - so what's the point? 2. Garbage collection on mobile/consoles. Yes, GC implementations have gotten better. Yes, you can work around the issues. But many of these languages GC implementations are often designed for desktop/server use, with copying implementations where performance severely degrades as the percentage of available memory decreases. On a console, that percentage is always near 0 - we use all parts of the buffalo. With mobile there's certainly more research in this area, and this will probably improve in the future, but it's certainly been a problem in the past. 3. Strings, strings, everywhere! Nothing kills perf like string operations. But string operations are a fundamental part of a lot of these languages, like Python or JavaScript/ActionScript, and you can end up having to be very careful or customizing the language itself (ScaleForm's direct access API being a good example of the latter). and for my religion/philosophy entry: 4. Static typing on consoles or GTFO. Seriously, gameplay code is the hardest part of the game to get good coverage on, because of its branchiness and special cases and all the stuff that goes into making something fun. Throwing dynamic typing into the mix just increases the QA burden and debugging difficulty. I'm skeptical that unit tests can provide enough coverage -- most of the really interesting dynamic typing gameplay bugs involve situations that are hard to reproduce let alone predict. You bring up Facebook, but the truth is Facebook has a unique QA environment - 500 million users. When they roll out features, they do so selectively to some portion of those users. That's a pretty good way to get coverage on any new feature! Amazon, Google all do the same kind of thing. So for web games, dynamic languages are good way to go. But for a console title, which has to be right The First Time, I disagree. So way back in 2000 I worked on a (simple) PC title that used Java as the game language and C++ for the heavy lifting. It worked relatively well.

I’m more a systems programmer, so from my point of view, here’s why I think there’s resistance to languages like Lua et al:

1. The lack of many JIT options on console. The consoles basically prevent you from shipping a JIT, which is fine (I can ship statically compiled code). The problem is this seems to mean not too many people are particularly interested in providing a JIT for development purposes. Mono seems to be supplying a IL environment for PS3/360 (anyone have experience with this), but information on it seems thin. You’re other option is interpreting the bytecode (slow), or porting an existing JIT to the platform (which I’m sure people have done, but due to the funky way console NDAs are, it’s very difficult to share such work). Maybe there are some more alternatives today since I last looked at this.

You could just statically compile, for sure, but then you’ve got the same iteration time problems as with C++ – so what’s the point?

2. Garbage collection on mobile/consoles. Yes, GC implementations have gotten better. Yes, you can work around the issues. But many of these languages GC implementations are often designed for desktop/server use, with copying implementations where performance severely degrades as the percentage of available memory decreases. On a console, that percentage is always near 0 – we use all parts of the buffalo. With mobile there’s certainly more research in this area, and this will probably improve in the future, but it’s certainly been a problem in the past.

3. Strings, strings, everywhere! Nothing kills perf like string operations. But string operations are a fundamental part of a lot of these languages, like Python or JavaScript/ActionScript, and you can end up having to be very careful or customizing the language itself (ScaleForm’s direct access API being a good example of the latter).

and for my religion/philosophy entry:

4. Static typing on consoles or GTFO. Seriously, gameplay code is the hardest part of the game to get good coverage on, because of its branchiness and special cases and all the stuff that goes into making something fun. Throwing dynamic typing into the mix just increases the QA burden and debugging difficulty. I’m skeptical that unit tests can provide enough coverage — most of the really interesting dynamic typing gameplay bugs involve situations that are hard to reproduce let alone predict.

You bring up Facebook, but the truth is Facebook has a unique QA environment – 500 million users. When they roll out features, they do so selectively to some portion of those users. That’s a pretty good way to get coverage on any new feature! Amazon, Google all do the same kind of thing. So for web games, dynamic languages are good way to go. But for a console title, which has to be right The First Time, I disagree.

]]>
By: Matt D/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-879 Matt D Sat, 19 Feb 2011 14:53:08 +0000 To answer a few random points from the comments: For the foreseeable future there will always be a need for a 'fast' or 'hardware' layer, which for the moment on will have to be C/C++. Write your vector and matrix classes in native code and expose it to the script. Every language I mentioned ( with the possible exception of LOLCODE ) has debugging support. As part of the implementation of a scripting language, time should be allocated for debugging and profiling support. Strong/Weak, Static/Dynamic typing is an idealogical argument which IMO doesn't particularly have a right answer. Good code can be written with all of them. Static type checking fixes a single issue, and is useful. A full suite of unit tests (which incidentally are a much easier to write in a dynamic language) can easily cover the same issues and much more. Shitty coders, write shitty code in any language, it can't really influence your language choice. The idea that 'scripting' languages cannot be used for is large projects or by their nature encourage you not to think is fallacious and backed up by hundreds of projects which are solely written in dynamic languages. Facebook, Mercurial and many others are 'real' software written in dynamic languages. Not every game needs to push the boundaries of the machine it is running on, I'm sure there exist games which can only be written using handcrafted assembler, but for most of us that is overkill. Matt_D nails it: treat script code as real code. It will pay you back one thousand fold. I'm glad no one took offense to the swearing :-) To answer a few random points from the comments:

For the foreseeable future there will always be a need for a ‘fast’ or ‘hardware’ layer, which for the moment on will have to be C/C++. Write your vector and matrix classes in native code and expose it to the script.

Every language I mentioned ( with the possible exception of LOLCODE ) has debugging support. As part of the implementation of a scripting language, time should be allocated for debugging and profiling support.

Strong/Weak, Static/Dynamic typing is an idealogical argument which IMO doesn’t particularly have a right answer. Good code can be written with all of them. Static type checking fixes a single issue, and is useful. A full suite of unit tests (which incidentally are a much easier to write in a dynamic language) can easily cover the same issues and much more.

Shitty coders, write shitty code in any language, it can’t really influence your language choice.

The idea that ‘scripting’ languages cannot be used for is large projects or by their nature encourage you not to think is fallacious and backed up by hundreds of projects which are solely written in dynamic languages. Facebook, Mercurial and many others are ‘real’ software written in dynamic languages.

Not every game needs to push the boundaries of the machine it is running on, I’m sure there exist games which can only be written using handcrafted assembler, but for most of us that is overkill.

Matt_D nails it: treat script code as real code. It will pay you back one thousand fold.

I’m glad no one took offense to the swearing :-)

]]>
By: Adrian O'Grady/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-874 Adrian O'Grady Sat, 19 Feb 2011 08:04:43 +0000 Actually writing good code in script is really much more demanding. A small subset of what script lacks to make it easier to code : -> Strong type, automatic statically type-checked: Most of language script think of that as the cool thing, but how do you catch any implicit cast. Even Flash ActionScript had to drop lazy type thing after 10yrs of pain. Need I says more ? -> Strict syntax : lazy syntax is just error-prone and time consuming. Javascript optional semi-colon makes it actually harder and does introduce bugs and nearly no one know really when it's needed... JavaScript ES5 "use strict" is an example of what jit compiler/interpreter has to enforce if they want to be able to do real work. -> Explicit variable management... (having a real hand on variable scopes, globals, closure behavior, locals, memory, gc) -> a way to optimize. It depends so much on the interpreter version rather than HW and if there is a change between language interpreter version... you may need one codebase per version... and throw all you've learned each version. Not speaking of the lack of profiler tools (L2 cache impact of you algo in that script ?) -> "Basic" tools (static analyzer, working debuggers, syntax enforcer, profiler...). really, really needed. JavaScript is a 15yrs language supported by huge software company, widely spread, and it's just starting to have decent tools (webkit). (decent but not near c/c++ toolset). (linked with the 3 point above) -> a sort of high-level entry : Makefile, link, explicit include,project setup has a good side, yes. The good thing is that it filters a very huge portion of script kiddies you'll never see in the c/c++ world. yes, it's needed if you don't want to inherit code done without any respect of any kind. You think you saw horrible code in C++, but in the script world "I've seen things you people wouldn't believe...". An worst than all above, what script enforce by essence: -> bad habit: "code before think". It's implicitly enforced by the "no compile" thing, because "hacking" code is so fast... So you'll end with people that doesn't code like use, as they never does step-by-step manual algo test, never move away from their screen coding, ending with lots of paste&copy code, and code "hacking" : "I'll just try move this variable around and see what it does..." Debugging is often where you loose the most time. Where languages should go is the caml way or the functional way, making sure before runtime execution with all possible ways, that the code you've written is what you intended, no more, no less. Script is good for very small-code base, prototypes that will be dropped or on platform where you don't have the choice... Time spent "word-fighting" is nothing compared to time spent debugging/maintaining scripts. Did you ever find yourself in hours of debugging script code for a syntax problem ? that just doesn't happen in C/C++. "Quicker, easier, more seductive." Actually writing good code in script is really much more demanding.

A small subset of what script lacks to make it easier to code :

-> Strong type, automatic statically type-checked: Most of language script think of that as the cool thing, but how do you catch any implicit cast. Even Flash ActionScript had to drop lazy type thing after 10yrs of pain. Need I says more ?

-> Strict syntax : lazy syntax is just error-prone and time consuming. Javascript optional semi-colon makes it actually harder and does introduce bugs and nearly no one know really when it’s needed… JavaScript ES5 “use strict” is an example of what jit compiler/interpreter has to enforce if they want to be able to do real work.

-> Explicit variable management… (having a real hand on variable scopes, globals, closure behavior, locals, memory, gc)

-> a way to optimize. It depends so much on the interpreter version rather than HW and if there is a change between language interpreter version… you may need one codebase per version… and throw all you’ve learned each version. Not speaking of the lack of profiler tools (L2 cache impact of you algo in that script ?)

-> “Basic” tools (static analyzer, working debuggers, syntax enforcer, profiler…). really, really needed. JavaScript is a 15yrs language supported by huge software company, widely spread, and it’s just starting to have decent tools (webkit). (decent but not near c/c++ toolset). (linked with the 3 point above)

-> a sort of high-level entry : Makefile, link, explicit include,project setup has a good side, yes. The good thing is that it filters a very huge portion of script kiddies you’ll never see in the c/c++ world. yes, it’s needed if you don’t want to inherit code done without any respect of any kind. You think you saw horrible code in C++, but in the script world “I’ve seen things you people wouldn’t believe…”.

An worst than all above, what script enforce by essence:

-> bad habit: “code before think”. It’s implicitly enforced by the “no compile” thing, because “hacking” code is so fast… So you’ll end with people that doesn’t code like use, as they never does step-by-step manual algo test, never move away from their screen coding, ending with lots of paste&copy code, and code “hacking” : “I’ll just try move this variable around and see what it does…”

Debugging is often where you loose the most time. Where languages should go is the caml way or the functional way, making sure before runtime execution with all possible ways, that the code you’ve written is what you intended, no more, no less.

Script is good for very small-code base, prototypes that will be dropped or on platform where you don’t have the choice…

Time spent “word-fighting” is nothing compared to time spent debugging/maintaining scripts.
Did you ever find yourself in hours of debugging script code for a syntax problem ? that just doesn’t happen in C/C++.

“Quicker, easier, more seductive.”

]]>
By: Matt D/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-872 Matt D Sat, 19 Feb 2011 04:20:10 +0000 I think what your friend is trying to say is that complex game code (which bits arent complex?) should be done in a language which actually has decent tools, and a suitable execution profile. writing your cache sensitive code in lua isnt going to work, nor is writing AI code in a language which doesn't have a debugger. can you imagine trying to debug complex HFSM's using printf's? I think the reason we default to c++ is that most of us know it rather well, we're confident we can write decent code, with a good execution profile, and we have a lot of tools (debuggers, profilers, memory trackers, etc) that can help us get the job done faster. Its not so much about language, its more about tools. Although for the love of god, why does lua default to global scope. WHY? *sigh* I think what your friend is trying to say is that complex game code (which bits arent complex?) should be done in a language which actually has decent tools, and a suitable execution profile.

writing your cache sensitive code in lua isnt going to work, nor is writing AI code in a language which doesn’t have a debugger. can you imagine trying to debug complex HFSM’s using printf’s?

I think the reason we default to c++ is that most of us know it rather well, we’re confident we can write decent code, with a good execution profile, and we have a lot of tools (debuggers, profilers, memory trackers, etc) that can help us get the job done faster.

Its not so much about language, its more about tools.

Although for the love of god, why does lua default to global scope. WHY? *sigh*

]]>
By: Pat Wilson/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-869 Pat Wilson Sat, 19 Feb 2011 01:44:54 +0000 It doesn't really matter which language you use. They just solve different tasks in a different way. There is no silver bullet like 'use python and your AI system will beat all other ones'. Same thing with all this DOD vs OOP (I'm a fan of DOD though): if you're skilled enough to code systems on C, you won't fuck up with C++ and vice versa if your mind works in a 'spagetti' way, your C-code would be even worse. Educate yourself, listen to all these smart people, read these blogs - that's the general advice, have a good weekend:) It doesn’t really matter which language you use. They just solve different tasks in a different way. There is no silver bullet like ‘use python and your AI system will beat all other ones’. Same thing with all this DOD vs OOP (I’m a fan of DOD though): if you’re skilled enough to code systems on C, you won’t fuck up with C++ and vice versa if your mind works in a ‘spagetti’ way, your C-code would be even worse. Educate yourself, listen to all these smart people, read these blogs – that’s the general advice, have a good weekend:)

]]>
By: Forrest Smith/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-866 Forrest Smith Sat, 19 Feb 2011 00:23:29 +0000 I don't think scripting languages are bad, but i've got a real problem with weakly typed languages. Lua doesn't appear to have type safety and I can't find much information about Python's type safety. What I don't understand with these languages is why, if I wanted to force a variable to be a specific type, the language can't let me do this. If x is an int, don't let me make it a string later. This would take a fraction of a second to typecheck a whole script and would save so many stupid errors. Maybe this is just me, but its frustrating enough that I don't want to avoid the relative safety of C++, even if I do have to wait 10 minutes for a re-compile. I don’t think scripting languages are bad, but i’ve got a real problem with weakly typed languages. Lua doesn’t appear to have type safety and I can’t find much information about Python’s type safety.

What I don’t understand with these languages is why, if I wanted to force a variable to be a specific type, the language can’t let me do this. If x is an int, don’t let me make it a string later. This would take a fraction of a second to typecheck a whole script and would save so many stupid errors. Maybe this is just me, but its frustrating enough that I don’t want to avoid the relative safety of C++, even if I do have to wait 10 minutes for a re-compile.

]]>
By: Tweets that mention And now you think I should be using C! » #AltDevBlogADay -- Topsy.com/2011/02/18/and-now-you-think-i-should-be-using-c/#comment-864 Tweets that mention And now you think I should be using C! » #AltDevBlogADay -- Topsy.com Sat, 19 Feb 2011 00:10:41 +0000 [...]

]]>