As someone who's had to deal with C++ since the last century, I find that one problem with C++ is that people who aren't experienced C++ programmers can't get shit done, especially in a code base where experienced C++ programmers have demonstrated their erudition and knowledge of C++ arcana in all its glory. In fact, the intersection of people who had the patience to learn enough C++ to get shit done and people who also have the patience or basic desire to actually get shit done (as opposed to programming wanky wrappers and stuff) is annoyingly small (this however is not true everywhere, I'd expect no such problem to exist with game programmers, for example.)
The fact that a language is terrible for newcomers is a real problem, and a newcomer is a very good judge of that even if they aren't a very good judge of other aspects.
Especially loathsome are those people who teach, say, undergraduates majoring in physics some C++ as a way to introduce them to programming. You might think that someone who manages to deal with the math needed to do physics would be able to absorb C++, and often you'd think wrong; one physics undergrad told an experienced programmer after trying to understand what the fuck cout<<x actually does, "your head is full of garbage!", by which he meant that the amount of completely arbitrary rules that you need to memorize was not something that dealing with math and science prepared him for.
From the above I conclude that people who have a semester's worth of experience in C++ might not be C++ experts but they certainly know enough to burn the instructor who chose C++ in the first place at the stake.
I agree. To truly learn and appreciate programming, you have to be able to enjoy it, first and foremost, and, unlike, say, Pascal, Python or JavaScript, the languages like Java, C, and especially C++ make that extremely hard for a novice programmer. This is because before you even begin to appreciate the ideas based on which those languages were designed and the languages' sophisticated features, you need to face the problems that these languages are trying to solve, and that takes time and programming experience.
It may sound strange, but I find assembly to be an appropriate language to learn programming. Not only your focus will be on what you are doing rather than on the language itself, you will get a feeling of what is really going on, and you will quickly appreciate - and fully understand - the the reason why C is useful and that it is a good, well designed programming language. (In the same way, with enough experience using C, one comes to appreciate C++.)
I'm not sure where that conversation would go. It prints to stdout. Would the student say the same thing about printf("%d", x)? How far down the rabbit hole did he want to go?
Stream insertion syntax os pretty bad, though, I'll agree with that. Especially when you want to print floating point.
The conversation then shifts to how it does this? What if I want to print to something else? Why if I want to read differently from a stream?
When you provide a shorthand that's all well and good but when you TEACH a short hand it's what's ONLY used by the students.
The students will assume there is no other way to read and write then using >> and << which is horribly incorrect. These are largely inadequate measures for reading and writing in my experience as you probably want to do formatting which printf just does better.
So many of the students in my CS class this semester can't do the first lab, which in all essence, is a tokenizer because they don't know that there are other ways for writing to, or reading from, a stream!
A short hand should only be used in a majority if it can do everything the long hand way can do.
Also for anyone interested what my first C++ project looked like you can see here:
I will agree with the point that the other methods of reading/writing from streams aren't taught early enough, and that formatted output is pretty bad with streams. I've actually written a wrapper around snprintf for printing in c++ (I should put that on github sometime)
Your project looks good. Two minor observations: 1.) You have 'using' statements in a header file. This is fine for a small project, but is considered bad form in larger projects (every file that includes that header will end up including the 'using' statements. This can cause collisions in large projects).
2.) Const correctness is a good habit to get into. (Ie, only pass non-const references if you are actually changing the object in the function)
I wasn't sure how const worked in this language so I decided not to mess with it yet.
Coming from Java I have a blanket policy that every variable is final unless needed to be modified. I've run into those pain points.
Your first observation is one I have some into as well but I haven't been taught how to do this.
For example if my header file needs to define the method:
void test(std::string something);
Is it bad form to them define the header in my cpp file as such?
void test(string something);
Isn't that also bad form? Coming from C some things like this could be done but very much shouldn't have been done.
I know for a fact that namespacing is one of the hugest benifits to large projects I just don't know how to use the tools provided by C++ to do it correctly. Java? Yea I can get anything you want nice and tucked away. But C++ with the way headers and namespacing works its difficult to obviously see what I want to do and how to get it done.
I'm not sure I understand the question completely. Do you mean "declare" instead of "define" in "if my header file needs to define the method"? Or are you asking about declaring the parameter to test as "std::string" in the header but then only as "string" in the .cpp definition, because of the presence of a using statement?
i think they want to make an impression: C++ is supposed to be a new language, and not just C with a class system + templates bolted on top of it.
i guess streams is supposed to be the new way of doing IO, never mind the circular inheritance mess and virtual function calls for getting new data.
The fact that a language is terrible for newcomers is a real problem, and a newcomer is a very good judge of that even if they aren't a very good judge of other aspects.
Especially loathsome are those people who teach, say, undergraduates majoring in physics some C++ as a way to introduce them to programming. You might think that someone who manages to deal with the math needed to do physics would be able to absorb C++, and often you'd think wrong; one physics undergrad told an experienced programmer after trying to understand what the fuck cout<<x actually does, "your head is full of garbage!", by which he meant that the amount of completely arbitrary rules that you need to memorize was not something that dealing with math and science prepared him for.
From the above I conclude that people who have a semester's worth of experience in C++ might not be C++ experts but they certainly know enough to burn the instructor who chose C++ in the first place at the stake.