I prefer C and ASM, myself.

Computer languages are just tools. You pick the tool based on the job you want to do. Since GUIs are naturally object-oriented they lend themselves to object-oriented development. All O-O languages have rich libraries to support GUI development. With GUIs, performance is not usually the primary concern (developer time and maintainability are) since waiting for user input is usually the bottleneck.

However, if I need to write a device driver, encode a crypto algorithm, or write a high performance server, I'll use C.

If performance was the only concern then we would all still be encoding in assembler.

I used to teach assembly in college some years ago.  But it's not really something you'd want to use to make a PC game.

No, Assembler would take too long to make the monstrous modern programs (also known as bloatware).

Regretable, but simply the way it is.

Visual Basic Felkethar? Och, poor lad.

These days I mostly only get to use scripting languages myself, but at least they are stringly influenced by C so I'm not offended by them. But VB? Ick.

Well I'm not a software engineer by training or experiance but rather a hardware guy, so I feel kinda dirty using ANY higher level language . I have to use VB to make applications to make the hardware do what I need it to do without involving all the software guys upstairs.

Fortunatly I use the programs to do a heck of a lot of hex and boolean calculations and mux bus communication so I don't feel like I've... totaly gone over to the dark side

I did try and make a game with VB once. I learned two things...

1) VB isn't very good for making games.
2) I suck at making games.

Felk the 01000010 01101001 01101110 01100001 01110010 01111001

Allow me a monent to categorize certain programming zealotry (note: the following is 100% joke):

I'm sorry any language that doesn't allow for pointer manipulation will never replace C/C++. There are too many really nifty things that you can do in a few lines of code with pointers that take two or three times that without.

Behold: the C/C++ Zealot.

You can distinguish the C/C++ Zealot by how he values the number of lines it takes to do something rather than the clarity of said code. The C/C++ Zealot tends to keep to his own kind, avoiding contact with more "evolved" Zealots, such as the Whooping Generic Programming Zealot. Of course, few other Zealots deign to approach the Whooing GP Zealot, for it is most aggressive and insidious, spewing forth types with truly bizzare names at an incredible rate when anyone approaches.

I find that C++ is over engineered, too many things added that - as stated - reduce efficiency.

Behold: the Pure-C Zealot

You can distinguish between the Pure-C Zealot and the C/C++ Zealot by the way that the Pure-C Zealot misunderstands the way in which C++ is considered "inefficient". They also attempt to visciously savage other Zealots of opposing alignment, such as the Parented Object-Oriented Programming (or POOP) Zealot. The POOP Zealot tends to win in conflicts with the Pure-C Zealot, as it brings a truly gigantic lineage of parents and children that really don't do anything more or less than it itself does. Even so, the Pure-C Zealot is usually able to escape with minor injuries by confusing its enemies with a trail of references to global variables defined in files far from here.

Joke over.

Personally, I think C# is ready for limitted game use. Not for the low-level "here's how you render stuff" part, but I could imagine that GC2's AI wouldn't be slowed down much by being written in C#. Indeed, the basic game rules of GC2 could probably be written in C# without any noticable slowdown. The primary problem with using Java is that the Java-to-C/C++ interface is painful at best and hard to deal with. Interfacing between C++ and C#, by contrast, is much simpler and easier.

Christ, Java is slower'n molasses. Not the language, but the virtual machine. Screw compatability, give me C!

The old stereotype. If you're willing to open your mind, take a look at this - these are benchmarks of a Quake port to Java. So much for "Java is too slow for gaming" ^^

A true thing is that the runtime needs some seconds to start, ie the program takes a moment longer to load. But that's becoming negligible on todays hardware, and the runtimes themselves get better too. And if I can use the time I saved developing (say, compared to C++) for more features, it's a win

Good Grief Martimus
"Assembly is obviously the most efficient, but I like FORTH as well - being a high level language. "
For time critical stuff assembly is the way to fly although you can shoot yourself in the foot. But FORTH, man that one will let you take your whole leg off. But it is nifty

There are too many really nifty things that you can do in a few lines of code with pointers that take two or three times that without

Sure. And you can also create nasty bugs that may be hard to track

And here I went around thinking they programmed the game by going into DOS mode and typing...

c:\>Copy con galciv2.exe

..and then just typed in the needed stuff

Nobody is perfeckt