phinds said:
My point is that if you don't learn sequential programming before OOP you'll have no idea how computers actually work and a lot of trouble debugging when things go wrong.
When I taught my C++ course, I didn't start on object-oriented programming (designing and implementing one's own new classes i.e. object types) until the second semester of a two-semester sequence.
Up till that point, the major differences between my course and a C course were:
- Input/output using iostreams (cout, cin, the >> and << operators, file streams) instead of C-style I/O (printf(), scanf(), file pointers, etc.).
- Text data (character strings) using the standard string data type (class) instead of C-style null-terminated char arrays.
- Collections of data (of the same type) using the standard vector data type (class) instead of C-style arrays.
For these, students needed to learn how to
use previously-defined object types (classes), e.g. for strings, myName.length() instead of strlen (myName); or myArray.size() for vectors instead of ... um, what?
for C-style arrays.
I considered it important to be able to
use this stuff before learning how to
create it. I applied the same philosophy to plain old functions. I had them
use functions from the standard library, and functions that I had alresady written, before having them
write their own functions.
I agree that even in these situations, compiler error messages could be rather intimidating. This was not only because of using classes, but also because of using templates, e.g. the vector class. I dealt with this by urging my students to write and compile programs incrementally (a few statements at a time), instead of trying to write the whole thing at once and throw it to the wolves, er, compiler. That would at least localize the mysterious error messages that they got. As they got better, they could of course increase the "number of statements at a time."
And of course, I was available to help them decipher the error messages that they got.
