Programming Language

Started by
63 comments, last by OldMan__ 19 years, 7 months ago
Hi guys, i dont want this to be a language war of any kind, but i truely dont get it, why anybody would start writing an engine in c++ (beside your boss insisting on it). My Background: I study computer science and have been programming since more than 6 years, and for the last 3 years as a part-time profession (started with basic *g*, java, c, c++ strange stuff like prolog, haskell and finally: python). I made two opengl-engines. One of them can be downloaded her "Tu-Wan'Hudan - Looking Like Ghosts" http://www.cg.tuwien.ac.at/courses/CG23/HallOfFame/2004/index.html Okay, so lets try to stay calm and discuss this seriously :-) Even in my personal surrounding I stand relativly lonley with my opinion that languages like Python should be used for everything (i hear stuff like "no serious computer scientist would code in a 'scripting language' ", etc..) C++ Pros: - Lots of examples/tutorials - Full control over computer (memory, etc.) - Very Fast Programms C++ Cons: - full controll over computer (do your own mem-managment, etc.) - no high-level-datastructures.. even with STD you're far away from the possibilites for example python gives you... In my opinion these Cons are enough reason to forget C++ instantly.. if there is something that helps me get the programm done fast: LETS USE THAT! even if the programm is 10x slower... you can always code the 1% of performance critical stuff in C++, but why the hell would i do the WHOLE project in such a low level, time-consuming language as C++. Okay, so to finally ask a question: Why are YOU coding in C++ and not in some higher level language? Don't try to convince my or anybody.. just tell me, what you think is so very best about C++ that you would never want to miss even if that means more work. Or is this a controversial point? I think its obvious that the coding time gets less, if the language gets higher. Bye bye
Advertisement
I'm coding in several languages these days. C++, VB.NET, D, C# and &#106avascript (if you want to count that). I use C++ as my 'main' language - why? I have no real reason other than it's the one I know best and feel most confortable with. I agree that there's an illusion that "all games should be written in C++!" as I see many people saying these days - I don't think it's necessarily true. I think it's really down to the fact that C++ is the industry standard language for games and that many programmers don't really feel inclined to change language.
I've personally used python a little bit, but mostly use C++ for games. I principally use C++ because of speed I guess, though for all I know I'm probably loosing that advantage through sloppy coding :p

If you look at the CPUtime/memory comparisons of languages, python doesn't fare very well. So unless you're coding all your time critical stuff as python modules, you might get significant slowdown. (Yeah, now someone just needs to point to some python rendering engine that handles half a million polygons a frame with shaders)
Quote:Original post by evolutional
I use C++ as my 'main' language - why? I have no real reason other than it's the one I know best and feel most confortable with.


I can see your point - men like the stuff best the're good in :-)
But what stops you from trying some high-level language.. just to get a taste of it. I would say for a C++-coder python.org (interpreted, truely OO, very highlevel) for example is a "no-brainer"... after reading 2 pages of tutorial you can instantly start prototyping a game-engine.

do you agree on the point that this will get you more work done faster? if so... why not try it?

Quote:
I think it's really down to the fact that C++ is the industry standard language for games and that many programmers don't really feel inclined to change language.


okay... that might very well be the reason. But i feel like this is limiting our possibilites as freelancers and small-team-game-programmers.

Or to see this from a different perspective: Carmack has always included some "scripting-language" in his games: write the gfx-engine (everyting in this area performance critical if we're talking carmack-style) as a scriptable, interpreted C++ thingy, all the rest (ki, content, whatever...) in the so produced higher-level language. I guess none of us is trying to compete with doom3... so lets do everything with a fast-coding-prototype language and optimize we're its necessary.

another thing: i believe most "real games" (battlefield, doom3, c&c) have been coded like that.. be it a scriptable-c++-engine or a data-driven-engine.

no one does game-content in c++. and instead of thinking "because they have enough time to make a flexible-engine" i think the reason is, programming too much in c++ takes too long ;)
There is a miss conception about Python.

When running py or pyc files it can be slower than a C(++) equilivant. But it is easier in most respects.

But you can convert your py(c) file to a executable. Fully machine code! aka fast.

It's called py2exe.

There is one really big pro for Python.
You can update without editing the script directly. :)
Quote:Original post by ch1pz
I principally use C++ because of speed I guess, though for all I know I'm probably loosing that advantage through sloppy coding :p


Well.. and I say speed is never an issue :-) If you're doing a game yourself you probably won't ever have millions of polys on the screen nor will the A.I. be eating all the CPU-power and how many objects do you have on the screen for coll-detection? what else can eat your cpu-power? md3-animation stuff.. okay... that and other game-content-specific stuff would be something definitly faster in a c-module for python (and would be logical as well... there are thousunds of ready-to-use tutorials out there... copy&paste, precompile and use as python-function).

most graphics stuff can be handled on the GFX, and in the near future none of us will really make the GPU hot.

Quote:
If you look at the CPUtime/memory comparisons of languages, python doesn't fare very well.


you're right... but the game-content (textures, vertex-lists, etc.) always takes 90% of the memory and stuff like linked-lists, or the heap and programming-stuff in generally is neglectible... lets say it takes: 128 MB. and i wouldn't know how to produce so much stuff to fill these 128 MB.


Quote:(Yeah, now someone just needs to point to some python rendering engine that handles half a million polygons a frame with shaders)


there is no such thing :))
Quote:Original post by mldaalder
There is a miss conception about Python.
(...)
But you can convert your py(c) file to a executable. Fully machine code! aka fast.

It's called py2exe.



Ah.. NO NO NO!!
py2exe only wraps your py-code, the python-interpreter and all needed modules into a lot of strange files and makes an exe that you can use to start the wrapped thing. but it's still interpreted python-code... no change in speed. only difference / advantage is, that you obviously dont need a python-interpreter installed because it wraps it within some dll...

the homepage says so too...
http://py2exe.sourceforge.net/


BUT: there is psyco, which convertes python-interpreted-code into machinecode on the fly during execution and without any need to do something special with your code:

Quote:
Think of Psyco as a kind of just-in-time (JIT) compiler, a little bit like Java's, that emit machine code on the fly instead of interpreting your Python program step by step. The difference is that Psyco writes several version of the same blocks (a block is a bit of a function), which are optimized by being specialized to some kinds of variables (a "kind" can mean a type, but it is more general). The result is that your unmodified Python programs run faster.
http://psyco.sourceforge.net/


worked very well for me... but eats a lot of memory.
Quote:Original post by sim27

But what stops you from trying some high-level language.. just to get a taste of it.

do you agree on the point that this will get you more work done faster? if so... why not try it?



Funny you should say this, I do most of my work in script these days. I write the game shell with a scripting interface and do a lot of the game work in scripts - why? Because as you said, it's quicker and easier [smile]
Quote:Original post by evolutional
Quote:Original post by sim27

But what stops you from trying some high-level language.. just to get a taste of it.

do you agree on the point that this will get you more work done faster? if so... why not try it?



Funny you should say this, I do most of my work in script these days. I write the game shell with a scripting interface and do a lot of the game work in scripts - why? Because as you said, it's quicker and easier [smile]



nice :-) so another believer
I see a lot of generalistic points of view, and i think that's a wrong way to start arguing about this.

My point is, there is a tool for each job.

For small programs, or even big ones, where speed is a non issue, high level programming languages are the best choice because they allow very fast development, with readable, stable, sometimes portable and fast enough code. When speed becomes a issue, it's also possible to leave most of the program as it is, and just code some core funtion in a low level language to meet the specs.

But, to say something like "forget C++ instantly" is absolutely futuristic. The same goes for C and assembly code.

For applications where speed is important a low level language is a must, along with skill to bend it to one's will. You don't see good fast games in Java, in Python, in Visual Basic, they are coded in C++, with c/asm cores.

There's a reason for that, speed.

Map editors, user interfaces, loading sequences, and more, might be coded in high level languages, but AI, graphics, sound, networking, and more, need speed.

Like i said, a tool for each job.

Until high level languages match that speed, or cpu processing power makes the speed diference insignificant, low level programming languages will have a, not so easy to forget, place in many programmers lifes.
"Follow the white rabbit."

This topic is closed to new replies.

Advertisement