Kaelan said:
3. Forget about "easier languages". I'd recommend going with C then C++ instead of whatever else (C#, Java, etc). You can pickup those in a weekend once you properly understand C++ - it's better to struggle with the low level details now, while you're still learning, than not learning it at all and later on having to correct a swath of misconceptions and bad programming practices/habits you may have built up because all the little details were taken care of for you behind the scenes.
Kaelan, I understand your reasoning and to some extent I agree with you. A lot of lazy programmers should learn a bit of C++ in order for them to be conservative with their memory management. A language with a garbage collector is a luxury that breeds inefficient code. That is, until you understand how the garbage collector works and you start specifically coding so that it can function correctly.
But I don't think a person who's never coded in his life should just jump into C/C++, and I don't believe any person can say they "understand C++" until they've been coding it for a few years. I've met a lot of junior programmers who say they "understand C++" and then when I ask them to write an overloaded assignment operator for a specific class they never get it right. Hell, even the experts have a hard time agreeing, e.g. Anatomy of the Assignment Operator [http://icu-project.org/docs/papers/cpp_report/the_anatomy_of_the_assignment_operator.html] and it's revised companion Assignment Operator Revisited [http://icu-project.org/docs/papers/cpp_report/the_assignment_operator_revisited.html].
This is basic principles, if you don't analyze your class from every angle or you update it and forget to update the copy constructor and/or assignment operator: BAM! memory leak.
I've glowcoded apps that have been running for years at military installations written by "C++ Experts" and found horrendously written code, memory leaks, and mem access violations/seg faults.
It's for that reason that I see more and more companies turning to languages that hold the programmer's hand. Even myself, I put my juniors on UI code in C# or Java before I let them loose on the algorithms in C++, if they fuck up in Java, at least they get a nice exception stack trace and it doesn't pull the whole system down. If you don't know a bit of assembly and you don't know how to traverse memory addresses to find out what your pointers really are referencing, I'm not letting you near a C++ debugger.
Starting with easier languages allows a person to feel what its like to create something and see it work. Starting out with C++ can be very disheartening and confusing unless you have someone around to tell why your code isn't working. This is a classic example:
char* getString()
{
char szStr[5];
szStr[0]='t'; szStr[1]='e'; szStr[2]='s'; szStr[3]='t'; szStr[4]='/0';
return szStr;
}
I've seen this many times in various forms, some compilers will warn you that you are passing an address to a temporary variable - a lot of them don't.
The problem with code like that above is that the access violation (or segmentation fault if you use gcc) almost never ever occurs where you expect it would or indeed even at the same place if you run the program a few times. It's the kind of problem that a beginner programmer would be stuck with for hours or days, and a lot of times they'll just give up.
In my opinion, step number one is to get the syntax down, Java and C# share almost the same syntax as C++ and that in my mind is a good starting point. If you're still getting syntax errors after your second compile you should slap yourself, write your syntax right the first time.
Then focus on OOP principles, once you understand classes and instances of classes you can focus on your memory model, how your compiler assigns space for arrays and objects. This you can't do without a basic understanding of Number Theory, you need to know how to convert between numbers of different bases, and what that means at an electronic level.
Move on to C pointers and then C++ references, you can't understand C++ references if you don't grasp pointers. Once you understand why the following is evil:
char* pchr = 0;
char& rchr = *pchr;
you can start focusing on all the other good stuff; headers and prototyping, macros, structs and C++ classes, member overloading and shadowing, templates, function pointers (I wish other languages had this) and much much more!
Finally, buy and read books on the subject, there's a lot of material available, written by much smarter people than yourself, C++ is not something you do over the weekend (like Visual Basic), it requires effort, patience and understanding. Understanding only comes when you acquire the knowledge from people who have already gone through the process.
Really, it takes years to wrestle C++ to the ground and make it your *****, most of the time it'll ride you like a disease riddled dollar-per-hour whore and leave you feeling sick, vulnerable and guilty that you paid for the experience...
...and wanting for more, because C++ is power, it lets you do what you want and you get a real sense of accomplishment when you get it to do what you want it to.
EDIT: That last bit there wasn't directed at Kaelan, it was directed at all beginner programmers in general.
