Teaching C++. Thoughts?

[xismn]

Hello,

While I don't know everything (I would say, not nearly enough) about C++, I've been thinking for a while, superficially perhaps, that I would enjoy teaching the language to interested beginners.
I'm not talking about an actual lecture - I was thinking more along the lines of writing a series of tutorials. I'm not even entirely sure I want to go through with it anyways - and it's not the point of this thread. I'd just like to hear some feedback about what "parts" of the language you folks think shouldn't be taught or emphasized.

I'm referring to the tidbits and pieces of misinformation that beginners get the most flak for, such as the use of system(), looping on eof to read files, etc.

While these things do have their place and application in the language, they are often incorrectly taught to newbies. Sometimes newcomers think they're programming in C++ when in reality they're programming in C.

I blame the countless bad tutorials and resources that are out there. TheNewBoston, for instance - endlessly praised for being the arbiter of C++ tutorials, doesn't impress me.

Do you think a tutorial series taught from the ground up in "pure" and modern (C++11, C++14) would spawn a "generation" of better programmers, or would it backfire and scare people away? Do we need seemingly archaic (and sometimes wrong) methods of teaching to keep things simple and intuitive? For example, would it make sense to omit even mentioning system("cls") to clear the console, and instead introduce cross-platform albeit more complex alternatives right from the get-go?

[Duthomhas]

No. Teach people that they don't need to clear the console.

[JLBorges]

> Do you think a tutorial series taught from the ground up in "pure" and modern (C++11, C++14)
> would spawn a "generation" of better programmers?

Yes.
The idea (what "parts" of the language shouldn't be initially emphasized) is not new:

May 1999

We want our C++ programs to be easy to write, correct, maintainable, and acceptably efficient. To do that, we must design and program at a higher level of abstraction than has typically been done with C and early C++. Through the use of libraries, this ideal is achievable without loss of efficiency compared to lower level styles. ...

Education must play a major role in this move to cleaner and higher-level programming styles. The C++ community doesn’t need another generation of programmers who by default use the lowest level of language and library facilities available out of misplaced fear of inefficiencies. Experienced C++ programmers as well as C++ novices must learn to use Standard C++ as a new and higher-level language as a matter of course and descend to lower levels of abstraction only where absolutely necessary.

Stroustrup in 'Learning Standard C++ as a New Language'

August 2000

Our approach is possible only because C++, and our understanding of it, has had time to mature. That maturity has let us ignore many of the low-level ideas that were the mainstay of earlier C++ programs and programmers.
The ability to ignore details is characteristic of maturing technologies. For example, early automobiles broke down so often that every driver had to be an amateur mechanic. It would have been foolhardy to go for a drive without knowing how to get back home even if something went wrong. Today's drivers don't need detailed engineering knowledge in order to use a car for transportation. They may wish to learn the engineering details for other reasons, but that's another story entirely.

We define abstraction as selective ignorance--concentrating on the ideas that are relevant to the task at hand, and ignoring everything else--and we think that it is the most important idea in modern programming. The key to writing a successful program is knowing which parts of the problem to take into account, and which parts to ignore. Every programming langauge offers tools for creating useful abstractions, and every successful programmer knows how to use those tools.
...
If abstractions are well designed and well chosen, we believe that we can use them even if we don't understand all the details of how they work.

Koenig and Moo in 'Accelerated C++: Practical Programming by Example'

January 2001

We are reviewing our philosophy in some detail in the hope that others interested in teaching—or learning—C++ can understand the motivation behind our approach and consider adopting it themselves.

Three principles underlie our approach:

. Explain how to use language or library facilities before explaining how they work.

. Motivate each facility with a problem that uses that facility as an integral part of its solution. The problem must be interesting in its own right, and not merely constructed to demonstrate the facility.

. Present the most useful ideas first.

Our strategy so far has led us to describe three fundamental standard-library facilities— vector , string , and struct —before even mentioning built-in arrays or pointers. In doing so, we have shown how to write substantial programs.

Koenig and Moo in 'Rethinking How to Teach C++ Part 4: Emphasizing the Library'

[wizebin]

No. Teach people that they don't need to clear the console.

Lol Duoas, we're programmers, of course we need to.

@xismn

You should do it- the most significant hole I see for new programmers is a straightforward way to get into GUI development- if you could get right into GUI development after introducing most of the standard language you could have some serious impact.

[Duthomhas]

we're programmers, of course we need to.

As programmers, your need should be to do the Right Thing the Right Way, or in other words, to learn how things work and exploit that.

Clearing the console is a mistake, because you have not learned how to use it properly.

    Propriety of restricting the user to a human at a terminal:
    http://www.cplusplus.com/forum/beginner/1988/2/#msg10636

    Types of console application:
    http://www.cplusplus.com/forum/beginner/1988/4/#msg14423

@xismn
I don't want to discourage you... the project you are thinking of is much larger than most people realize.

Still, I have to agree that doing something useful with GUIs is a good incentive. Just don't let the GUI stuff take over. The most difficult thing people have with C++ is learning to deal with streams properly (IMHO).

[Cubbi]

xismn wrote:

Do you think a tutorial series taught from the ground up in "pure" and modern (C++11, C++14) would spawn a "generation" of better programmers, or would it backfire and scare people away?

I think that a C++ tutorial that would get enough expert approval to earn a place on The Definitive C++ Book Guide and List http://stackoverflow.com/a/388282 would be tremendously influential and beneficial. I also think it's a very difficult undertaking.

If you're just doing something because you "would enjoy teaching the language to interested beginners", you don't need anyone's approval. Becoming a better educator and dealing with complex topic, is a worthwhile personal goal even if you're not an expert: you might be the next Scott Meyers.

I'd just like to hear some feedback about what "parts" of the language you folks think shouldn't be taught or emphasized

I think all parts should be taught, the question is about order and emphasis. The modern textbooks: the PPP and the Primer, present an order that I think is the best one we have.

Do we need seemingly archaic (and sometimes wrong) methods of teaching to keep things simple and intuitive?

That seems to be a contradiction. Archaic methods (like modeling data structures using dumb pointers and explicit memory management) are nowhere as simple as post-1998 C++ using the standard library, and C++98 methods (like iterator-based loops or endless push_backs/inserts to populate a container) are complicated compared to range-for loops and list-initialization of C++11. The farther you get in modern C++, the simpler it gets to *use* the language, and, as JLBorges quoted above, "Present the most useful ideas first."

For example, would it make sense to omit even mentioning system("cls") to clear the console, and instead introduce cross-platform albeit more complex alternatives right from the get-go?

I don't think I've "cleared the console" ever in all 20-something years of my professional career. Present the most useful ideas first.

[xismn]

_{Duoas wrote:}

I don't want to discourage you... the project you are thinking of is much larger than most people realize.

Not at all! I'm sorry for not making myself clear in my first post - I don't think I'll go through with the idea, but thinking about doing it made me wonder if there are things that shouldn't be taught. You've given me excellent feedback by saying:

Teach people that they don't need to clear the console.

- receiving that sort of feedback is what I wanted this thread to be about, since teaching people to clear the console is something that shouldn't necessarily be taught (or, they shouldn't be taught to assume that a human will be sitting in-front of the terminal at all times).

I realize it's sort of like saying "How can we teach beginners better ways of clearing the console for their console game" when they shouldn't even be trying to make a game with the console in the first place. That isn't how I meant it, it was just the first example I could think of.
Which leads me to say that not only do I blame bad tutorials, but I also blame wave after wave of newcomers who are interested in nothing but programming games.
Of course there's nothing inherently wrong about that, but it perpetuates this notion of treating the console like some kind of "game engine base" - I hope I'm making sense.

@JLBorges

That Stroustrup quote said it infinitely better than I could have, thanks for that.
I especially appreciate the Koenig and Moo quote - makes you think of all the things we take for granted...

Also, thanks to everyone else as well. I will re-read what you've written, and this thread is obviously still open for anyone else who'd like to join in.