Every so often I get an email from someone just embarking on a career in programming. Inevitably they ask the question: "should I learn C before I learn C++?" It sounds like a simple enough question, but there is no simple answer. Before I even attempt an answer, I must ask what this question really means. After all, since C is a near-perfect subset of C++, it is not really possible to learn C first, any more than it is possible to acquire a vocabulary "before" learning English. Usually, though, the question can be translated to something like this: "Out of all the possible subsets of C++, should I learn the C subset first?"
This is one of the questions that Bjarne Stroustrup, the inventor of C++, addresses in this month's issue of CUJ (see "Learning Standard C++ as a New Language" on page 43). Bjarne makes a strong case that new programmers should not learn the C subset first, lest they pick up bad habits. If you're wondering just what kind of bad habits can be picked up learning good ol' C, I invite you to read his article. One way to state the problem is that C exposes too much machinery to novice programmers before they are prepared to deal with it. To make all that complexity manageable, C code examples make unrealistic assumptions: strings will always be small, memory will always be available, etc. The danger for new programmers is that they will never learn the real way to manage complexity, which is not by crippling their code but by applying abstraction. In fact, many of us know of programmers who dive right into coding without identifying a single useful abstraction. Whether such programmers are products of nature or nurture is endlessly debatable (probably both), but in either case we ought not encourage them. Bjarne's article presents an interesting alternative to the "just get something working" school of programming.
Still, before we abandon it wholesale, we should clarify what we mean by "learning the C subset first." In the extreme, it might mean forgoing the convenience of cout before mastering, say, the intricacies of qsort. The sooner we're done with such rigid approaches the better. On the other hand, the C-first approach might include some important teaching concepts — concepts I would hate to throw away. It might mean, for example, gaining a thorough understanding of primitive types before relying too heavily on templatized libraries. Am I contradicting Bjarne's article? No, I believe I am complementing it. Bjarne's article says, in part, that we should not toss new programmers into the trouble-prone parts of C that C++ so nicely transcends. I couldn't agree more. But things like primitive types, declarations, and control structures are not in this category, and they cannot be transcended.
Maybe we should finally retire this question of whether to learn C first. It has always generated more heat than light, and with Java entering the fray, it has become practically meaningless. The big problem in learning C++ is no different in principle than learning any other language. It is the old Catch-22 of needing to grasp the whole before understanding the part, and vice versa. As with all impossible tasks, the greatest resource for tackling this one is not the perfect methodology but an open mind.
Marc Briand
Editor-in-Chief