What I do is follow the trend; I do what PRO game developers do because, if you do, at the end you will achieve the same goals and results. It's just a matter of logic deduction.

Another thing, if virtually all the modern tools/games/engines are made in C++, it's because it has to be very versatil and rewarding (Valve or Epic can't be wrong), thus, needs some time to understand and learn; but when you do it, the results are limitless.
[/quote]

And they are designed this way due to legacy and existing requirements - those are not the same requirements that a beginner is going to have.

Also there has been a shift to the vast majority of in-hosue tools being written in a .Net language.

Most games in existance are probably Flash or otherwise based as such C++ has no relivance there either.

AAA game production, staffed by experianced people with specific requirements, is not a guide for where someone should start regardless of their ultimate goal - it might guide their process as they progress however first of all you have to learn to program and as such what pros do is not important.

And even if you fall back to doing char * strings or <type>* memory allocation you now run into the world of no bounds checking where you can do as you like and nothing will tell you otherwise until something blows up in your face.

I've seen beginners confused by things relating to 'access violation at address 0x000000c' which I can look at and say 'oh, it's this...' right away but they have no idea about. And yet allocating instances of types and calling functions on them is central to C++ but not for learning to program and can be taughted better in language which tell you via better error messages what has gone wrong. Try missing of a ';' somewhere in a header and watch the explosion of error messages which happen due to one tiny syntax error which has no impact on the ability of someone to learn the basics of programming.

Hell, there was an example recently of someone being confused because they could apprently call a function via a null pointer to a class without things going wrong.

The C++ standard itself is known for using the word 'undefined' or 'implementation defined' through out its language.

None of the things I've mentioned above are 'advanced' and yet I've seen over the years people repeatedly trip up over them and then the resulting cryptic error messages/reactions from the runtime which can come about from it.

Edit: you can also add to that list compile times, header files, pathing issues and libraries.
Again none of those are advanced but being forced to deal with them just to learn is, to use your phrase, 'insane'.

He'll learn the best way to do the things he's been doing later. Just like when you start off writing code like int box1, int box2, etc, and then later you learn "Oh, that's what arrays are for. Bad habit erased."

But it's not just Bad habits like that - C++ carries with it a massive legacy and with it comes 'advice' which might have been important 10 or even 5 years ago but these days is worthless.

New C++ programmers, the ones who seem to defend the language with such tenacity (or ones who only know C++ like it is the only thing worth knowing), are also the biggest source of 'not made here syndrome' - many shunning the standard library as if it is some slow and horrible thing, instead favouring that own bug ridden versions, because they once read somewhere that it was slow. This persists going forwards and instead of taking advantage of tools which exist they go on to try and reinvent everything because they feel somehow they will 'learn more' (also the classic excuse of someone who wants to make a game but believes making an engine first is a good idea).

This is a mind set which is VERY hard to break and one which continues to be recycled from programmer to programmer as someone new starts all the other newbies around them just tell them what they have done themselves.

(I figure it must be some kind of self reinforcement cycle - "if someone else does it then I can't be wrong" but that's far far off topic).

All of the above is why, when compared to other languages, C++ is lacking.

Yes, C++ has it's strengths, one of which is being on all platforms and other of which being if you know what you are doing you can get more out of it than maybe you can in another language HOWEVER those two arguements are utterly moot because they are advanced topics (often requiring knowledge of the target platform and how the code generation can work) and you have already stated that advanced things don't matter to beginners.

When you are starting out getting told what you are doing wrong is more important than speed or frankly other considerations beyond learning the art of programming.
C++ makes this harder than it needs to be.
[/quote]

This was by far your best post. You used specific, concrete examples and attacked the ideas I presented instead of attacking me, I love this post. Now here's my response:

I've come up against a couple of the things you mentioned, and usually after already getting a couple of days into coding something. It was frustrating, I was confused, there were few answers, and it would have been easy to quit. But it was also exciting. It's fun making horrible mistakes and then learning why they're mistakes and what makes them so wrong in the first place. There's no better way to learn about something than to try really hard at it, fail, and then ask people who know better than you "Why did I fail?" It will always be better than having people warn you beforehand: You should absorb what you can from what you read/are taught, try it out, and then go back to learning with the new perspective you've gained from putting it in action: You can relate to what you're reading.

This is my personal philosophy, and you may agree or disagree.

And what you bring up also points to a very valid concept I neglected, but should have mentioned: There are some languages that might be better for those who want to learn to program games, and then there are some better for people who want to make games. I think it is misguided to try to write your own huge libraries/tools/engines when you can just build on previously done work, but then again the people who justify it by saying "I'll learn from it" are being sincere. Most likely, they aren't just interested in making games, but also understanding the basic inner workings of games. They want to know why the cool stuff works just as much as they want to make the cool stuff.

To that end, it's a bit harder to find a distinction between learning to program and learning to program with the technologies at your disposal. If a person agrees with you, they'll think that C++ is overkill, or too burdensome, and they probably think it's a language that requires too much technology learning at the cost of programming learning. If a person agree with me, they probably feel like they're interested in both learning the foundations of programming, and some powerful technologies to program with.

Again, it's just a matter of personal discretion rather than some god-given guideline. Completely subjective.

C++ is harder to learn but I would rather have someone on my team whose resolve has been tested than someone whose resolve has not.
That being said, going with another language as your start is not so bad as I make it seem either. Again you really need to gauge this for yourself. Few people will blame you if you discover that C++ is too much to learn as a beginner. But you should at least try it out before you dismiss it.

I do feel that some people are making C++ seem more horrible for a beginner than it should be, and I agree with points you have made in your posts.
On the other hand, most of the people making C++ out to be a nightmare (myself included), have experienced C++ in a production environment. My impression (possibly incorrect) is that most of the posters avidly defending C++ do not share this same experience.

My daily work involves tracking down and squashing the kind of bugs that even highly experienced developers introduce to a large C++ code base. The type of bugs caused by triggering undefined behaviour in the language, misinterpretations of the language standard, compiler-specific edge cases, and obscure threading and allocation issues (which are often platform-specific).