Where to go next?

[Disch]

IMO learning C++ using something which doesn't requires to understand C++ syntax isn't the best thing.
When learning C++ you MUST learn the syntax and use it

*facepalm*

I guess "language" would have been a better word choice than "syntax"... but still.

My point was that you don't need to know all the ins and outs of C++ in order to get it working. Which does make it ideal for beginners because a beginner can't understand the ins and outs of things until they can write code to experiment and figure things out with.

You can learn to use SDL surfaces without fully understanding them just like you can learn to use strings and cout without fully understanding them. That is what I was trying to say.

However, you can't use it without understanding what an object is, because that's what the interface uses.

Sure you can. Perhaps you expect newbies to understand every single line of code they write, but that simply just isn't the case in my experience. The first thing people tend to do is copy/paste something that works, and use examples to figure out a basic concept without fully understanding how that example works. Then they start coding from there.

In a sense, they add their own layer of abstraction by using pre-formed code.

Here's a perfect (read: typical) example:

http://cplusplus.com/forum/beginner/8231/

He's having trouble because he's using cin >> value; where value is an integer, and he's wondering why he's unable to tell if the number entered is not an integer. Because in his mind... cin >> value; is the magic black box to get information from the user. I've only been coming to these boards for a few days now, but this kind of question seems to come up all the time

These people clearly don't fully understand cin, yet I'm sure you don't have a problem with them attempting to use it. I don't have a problem with it either -- and I hope they figure it all out, and I'm willing to help them figure it out when I can. But this is what I'm talking about. Abstraction of the concept versus understanding the underlying process. The former always comes first.


-------

In any event I suppose I should just drop this. I'm obviously in the minority, and I'm not about to make a new set of tutorials and documentation to revolutionize the C++ learning process for the average newbie. So even if I make a succesful and convincing argument, any point I make here is moot.

Ah well it was fun. =D

[helios]

And that's exactly how I think people should not learn. I do support experimentation, but not right from the start. What you're proposing leads to an incomplete understanding of the infrastructure, which sometimes happens to be necessary to understand what happens on the surface, which is necessary when (not if) things go tits up.

Your example is perfect to demonstrate why you need to understand why one should first understand, then write. Not the other way around. Or are you suggesting that if people were taught "cin grabs characters from the standard input (whatever that happens to be at the time), parses it according to the type of parameter that was passed to operator>>() and assigns the reference. If the parameter cannot be parsed, such and such flags will be set" instead of "cin is a magic box that takes input from the user and puts it in a variable" it would produce worse code, instead of better? Sure, the people with a limited attention span would leave before getting to streams, but I think that's an advantage, not a drawback.

[Disch]

And that's exactly how I think people should not learn

It's how we all learn. The only difference is the scale on which we do it.

- you know that "example" is a string
- you know that strings are arrays of characters.
- you know that characters are represented digitally by numerical values
- you know that numerical values are represented by series of bits
- you know that bits are represented by different voltages running through electrical components.
- you know that voltage is the carrier bandwidth of an electrical charge
- you know that electrical charges can be of electrons or ions
- you know that electrons are negatively charged particles that orbit the neuleous of an atom
- etc

There's always something lower. There's always something more detailed. Everything is abstracted. The question is... where do you draw the line? And it's not a question that can be answered the same for everyone -- different people learn different ways.

But I can tell you, I've noticed that people (generally) learn best going top->down, though of course the ideal starting point (the "top") for them may vary. I'm not just talking about beginners, but veterans, too.

Think about it... when you're designing a program, and are laying out how you want to organize your classes, you're looking at the overall picture first then breaking it down into smaller, more detailed sections. You don't jump on the first object you think of and start coding its interface without giving a second thought to any other part of the program (at least I should hope you don't). You always start with the big picture, then work your way down. It's just how the mind works.

What you're proposing leads to an incomplete understanding of the infrastructure, which sometimes happens to be necessary to understand what happens on the surface, which is necessary when (not if) things go tits up.

And when that happens, that's when the programmer goes lower and gets a firmer understanding. This may not be ideal, but it's the way it works in reality. See any number of posts on this board (including the one I linked). He was thinking abstractly, but now he needs to get into deeper details if he wants to progress.

What you propose gives me the impression you don't feel C++ should be a first language, and that everyone should start with assembly (or machine code written by hand in a hex editor). That surely will give them a firm understanding of everything from day 1. But of course I'm sure you agree that is completely nonsensical

Or are you suggesting that if people were taught "cin grabs characters from the standard input (whatever that happens to be at the time), parses it according to the type of parameter that was passed to operator>>() and assigns the reference. If the parameter cannot be parsed, such and such flags will be set" instead of "cin is a magic box that takes input from the user and puts it in a variable" it would produce worse code, instead of better?

No. Knowing details is always better, and more knowledgable programmers will generally produce better code. That wasn't my point at all. I'm talking about the easiest way to learn. In the end, experience teaches all, I'm just saying that the way in which you teach yourself should be easier on you. Abstract concepts are easy. Low level details are not.

Sure, the people with a limited attention span would leave before getting to streams, but I think that's an advantage, not a drawback.

So...intentionally making a language hard to understand is a benefit because it scares people away? I can't possibly comprehend your motives for this statement other than elitism.

EDIT: yeah I know I said I would stop. Sometimes I just can't resist. =x

[helios]

No. I do think C++ is not a good first language, but I propose exactly the opposite. Instead of starting with a language that gives less abstraction, start with a language that gives more.
C++ only gives a false sense of abstraction. While on one side you're doing std::cout <<etc;, passing pointers without realizing it (references and all that), on the other you have int v[]={1,2,3,4}; and keywords like static, register, and volatile.
There have been languages that do a good job of hiding what's below for a long time, but neither C nor C++ are in that list. If you want to learn C/++ it should be learnt from the bottom (when I say bottom, I mean as low as you can get without actually starting to learn Assembly) up: when you do declare a variable, here's what happens; when you declare an array, here's what happens; when you pass data by value, here's what happens; when you pass data by reference, here's what happens.
That's how you understand C/++. C was never designed to be taught to novice programmers. It was designed as a portable Assembly that gave more control than other languages over what was going on behind the scenes. C++ has a similar phylosophy. I don't see why either language should be taught as a higher level abstraction when it's clearly not.

It's not elitism. If you can't wait until week 3 of the course (after variables, arrays, functions, classes, and some inheritance have been covered in detail) to start using streams and understanding how they work, I don't think you're cut out to be a C++ programmer. Note that this suggests that the course is not introductory to programming, so the students are expected to not require visual feedback to know that their program is working, and thus don't need to print.