Judging by the arguments given, I think that I will opt for C# or Python. While it seems to be the common argument that Python is more beginner-friendly, I'd like to avoid requiring anybody to whom I may distribute executables to download Python, and I would rather my first language be somewhat similar* in terms of syntax to languages I might use in the future. I'm also planning to develop primarily for Windows, so I don't have many issues with opting for something requiring .NET. I also would be willing to use Mono if required.

However, I'd rather not ignore Python so quickly. Could somebody please give me a better understanding of how C# compares with Python? I'm wondering how they compare in terms of execution speed, abilities, syntax*, and such. The ease with which I can learn a language is less important than those concepts for me.

Also, chronomex: Not many of my friends are programmers, sadly. Those that are would likely be annoyed trying to teach me.

* How similar is the syntax for each to other languages? Would one be better to help me comprehend code from other languages? I'm not expecting to apply the same principles across code, but I do believe that learning one language could help improve comprehension of others.

Because until recently Mac hasn't had enough market-share or run on the same hardware (the Intel switch was in 2006) as Windows/Linux machines. And, to some extent, because Microsoft has played dirty to keep people away from OpenGL. Trying to support DirectX AND OpenGL is bad news unless you're an AAA studio (Valve, Blizzard); but indie developers (go look at the last n Humble Bundles) who work only in OpenGL have no problem.

There are 3d engines that work with both directx and opengl, so cross platform issues aren't bad for open source projects Ogre is one such example.

C# is trash on anything that isn't Windows. You do *not* want to have Mono as part of your learning experience.

Python is slower in general, but it has an fantastic syntax that requires you to have good coding practices and it has modules to do whatever you want - from games with SDL and OpenGL bindings to UIs with wxPython, pyqt, pygtk, etc... Super powerful, super easy.



No, MS simply made a much, much better API. That link is full of crap. DirectX had "won" *long* before Vista came around. And the claim that OpenGL is more powerful is flat out wrong. DirectX is the one creating fancy new APIs and features. OpenGL has been fumbling around for far too long, and the long awaited and much needed rewrite was essentially killed by Apple. Apple has far more to do with OpenGL's actual death than Microsoft does - as Apple blocked the plan to make OpenGL competitive again.

Listen to this man.


I'm not convinced you actually read that article. OpenGL has less overhead (so says NVidia, according to the link); and, as it points out, OpenGL has the benefit of vendor extensions to speed along support for new hardware features. DirectX has to wait on Microsoft to release actual upgrades. I agree that the OpenGL API is pretty bad, and I haven't worked with DirectX enough to say which is worse, but the rest of the link stands.

Well I knew that you were a strong advocate of C++ over many other things; but thanks for clarifying that

(Btw, people with half a brain are pretty dang intense, since the subset of your posts which they've read all over cemetech definitely include those about python, which you briefly mentioned [not repeatedly] before my post ... but perhaps I should be careful about making general claims about other people's stance, so touché)

The nvidia talk it is referencing is both a dead link and from 2006. One of the major things DirectX 10 and 11 have done is to address that overhead. Microsoft actually did the rewrite that OpenGL has been unable to do. And perhaps most importantly, it has added multithreading support.



No, that's not how it actually works. What actually happens is Microsoft, working with ATI and Nvidia, defines a new set of features and releases that. *THEN* the hardware comes out that supports it. I cannot think of a single case where DirectX has played catch up to OpenGL or what the hardware supported in the last 10 years.

In the specific case of tessellation, which the article calls out, the capabilities in ATI's OpenGL vendor extension are fairly different from what is in DX11. And, of course, the OGL extension was only supported by ATI - so nobody used it.

And regarding WebGL, that's OpenGL ES 2.0, not OpenGL (and yes, they are *very* different).

This is getting a bit off topic...

I see that a lot of us are trapped on the notion of language capability. We are talking about a beginner here though; you don't just hand a newborn baby a grand piano and expect them to be making magical symphonies by age 1. You start them off with a toy piano that, while imprecise and kind of useless, gets them accustomed to how a piano works in an accessible fashion.

Much the same, I would not hand a beginner a copy of GCC and K&H for their first programming experience. For a beginner, accessibility trumps power. As I stated before, the speed of development in C# is much faster due to the powerful debugging capacity and the great classes and abstractions that it provides, which would be more useful for teaching a first timer. C would just incur headaches.

Whenever someone approaches me to ask "how do you program? Teach me C!" and I'm feeling benevolent and agree, the very first thing they invariably ask is how to display pretty graphics on the screen for a game. In C, I would have to tell them all about 3rd party libraries in order to get IO that is suitable for a game. Then I have to drag them through the convoluted process of setting up SDL, SFML etc, which will only serve to confuse and bewilder them. When they screw up the program itself, GDB will also be an unfortunate obstacle for them, even if they are using a pretty IDE.
In Visual C#, I can just pull up a windows form designer, hook the validate and keyboard events, write how to capture keys in a simple manner and give them a quick rundown on all of the drawing functions, which all have straight forward functionality. With the advent of Visual [.NET Language] Express, it's easier than ever to get someone started with C#, too. The syntax of C# will also carry over to C++ fairly well.

Just remember, this is for a beginner. C is not nearly as friendly a guy as C#.

Good lord, do you live in the -s-t-o-n-e- -a-g-e- seventies? There's no reason to use a command line debugger for C in a graphical environment, ever.

Yup. Hell, you can use visual studio and get a really nice debugger!

*AHelper points at KDevelop's GDB integration if on linux and hides.

GDB integration is wonderful on Code::Blocks and comes quite close to the Microsoft C# debugger, though there are always those unfortunate cases of stack and buffer overflow that can be hard to debug no matter how much your debugger analyzes the memory. Though I suppose that GDB in conjunction with a static analysis tool could probably be great. But there's my point! In C#, everything is built in. No need to worry about all of the decentralization involved with C and C++. The standard is centralized, sure, but none of the implementations are, which can confuse and bewilder by way of too much variety.

(I will make a side note here: VC++ is not C++. It's a blasphemous concoction that should have never existed. You should go the way of C/C++ to free yourself, not lock yourself down with MFC and other trappings.)

I use GDB at a command line. Well, what I really do is litter printf's through my code, but in a pinch I'll use GDB.

Don't confuse the VC++ compiler with all of the MFC stuff that most people use with it.

Kllrnohj: wait, really? printfs are of course the first line of defense, but I haven't used GDB at the command line since I had to do assembly language stuff with it for a class. You don't have an IDE with graphical integration?

I only use gdb from a terminal as well. It was how I was taught, although I am sure that a gui would be easy to learn as well.

I've just never bothered to hook it up. I don't build with an IDE, which makes it more complicated, and combine that with doing remote debugging setup with a script that depends on environment variables that vary per device & config (and setup with yet another script).

For most of the native issues I hit I'm either interested in what the sequence of events was or it is timing related and printf just works better for both of those. Hooking up a debugger also adds noticeable overhead, which is annoying.

When I'm doing Wii development, I don't have any hardware debugging tools, so I have to shove relevant information from the crash dump in to command-line GDB. It's effective enough, but for programs that aren't cross-compiled there's little point using CLI GDB if you're already using a graphical context.

VC++ is C++.
I also would suggest starting with C#, if you havn't decided.
When you do start programming C/C++, use VS if you are just programming for Windows.

I'm with kllrnojh on the printf's, when working on tilp and some of my own projects the first thing I do is shove printf's in there and if that fails pull out gdb, from the command line. Than again most of the things I've been coding I've been testing and building from the command line anyway.

Oh, I suppose it makes more sense if you're doing remote debugging. And, as you point out, debuggers really don't help much if you're dealing with a timing-related Heisenbug.