Many Languages or One?

This question comes up all the time: "Should you learn many different programming languages or stick to just one?" Many programmers will jump on this one with a quick answer. Of course you should learn many languages if you want to be a great software developer. We hear this advice so often that it requires no proof or explanation.

The first time I read the "learn many languages" theory it was in The Pragmatic Programmer: From Journeyman to Master:

Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet.

Of course this is good advice if, like the subtitle says, you're a journeyman programmer looking to become a master. Is this the same advice we should give to everyone, though? What about beginning programmers? I'm not so sure.

Generally speaking, beginning programmers fall into two categories:

1. College students
2. Self-taught programmers

For the purpose of this discussion I don't think it really matters which group you fall into (despite what I said before). If you're a college student, you probably don't have much choice but to learn the syntax of 6-8 different programming languages in your first couple of years of school. That shouldn't hurt you, because you won't learn much depth on more than one or two of them. If you're self-taught, you probably have more control over how many languages you learn.

Let's take a look at what you should concentrate on when learning a programming language:

1. Basic syntax (data types, variables, operators, conditionals, loops)
2. String manipulation
3. Compound data types (arrays, linked lists, hash tables)
4. Basic algorithms and libraries
   
5. File input and output
6. Processing files (plain text, HTML, XML)
7. Error handling
   
8. Paradigm-specific details (procedural, object-oriented, functional)
   
9. Managing memory (manual vs. garbage collected)
10. Multi-threading
11. Database access
12. Network communications

The list could go on, but I think it's just about everything you should know about a language before you can claim (for example, on your resume) that you know that language. Most good books on a given programming language will include a chapter or two on most, if not all of these topics. But you can't just read one book from cover to cover and say you know a programming language. You have to do the exercises and write some real code (at least a few projects) before you can make that claim. That takes some time.

Most college courses aren't organized to teach you everything you need to know about a language, either. A 10-15 week college course will either touch lightly on several of the topics in the list above, or it will go very deeply into one or two of them. You might take several courses before you've done enough projects in one programming language to really know that language well. Consequently, it takes a couple of years of college to get a really deep knowledge of any one programming language.

Many supporters of the "one language per year" doctrine will say that learning a new language is good because it forces you to think about problems in a different way. This is just a new way of saying "think outside the box." This is almost always good for experienced programmers. Learning new languages will help stimulate you to find better solutions in your main language.

However, "one language per year" is almost certainly bad advice for a beginning programmer. You don't need to start thinking about new ways of doing things if you don't understand the old ones. Learning your first programming language to the depth necessary to solve many different real-world problems will take you more than one year. It won't help you to learn the basic syntax of two languages if you can't solve problems in either one.

My final advice to beginning programmers is this: You should give your first language 2-3 years to really take hold before you branch out into other languages. If you want to be a good programmer you have to know how to do a lot of different things in the main language you work in. Problem solving skills are certainly important, but you need to be able to implement a solution to a problem. If you spend the first few years of your programming career learning the basic syntax of many different languages, you won't have the depth you need to solve real-world problems in any of them.

Should I Learn C or C++?

The question comes up quite often, "Should I bother to learn C, or go straight to C++?" Many beginning programmers wonder if it's worth it to spend the time learning C, when they know a more advanced language is readily available. Others wonder if they're going to be missing out on anything important if they skip C, and proceed directly to C++ without passing Go or collecting $200.

While it is true that well-written C code will normally compile under C++, C is not a proper subset of C++. There are a few differences that can make a valid C program invalid in C++. The easiest examples to illustrate involve the addition of keywords such as new and class to C++, which were not reserved words in C. The following (contrived) valid C program will not compile as C++.

int main(void) {
 int class, new; // both class and new are C++ keywords
 printf("Enter two integers > ");
 scanf("%d %d", &class, &new);
 printf("The two numbers are: %d  %d\n", class, new);
 printf("Their sum is %d\n", class + new);
}

Another difference that's often cited between C and C++ is that C supplies an implicit cast when a void pointer is assigned to a pointer of a specific type, while C++ requires an explicit cast. The following valid C code will not compile using C++:

void* ptr;
int *i = ptr;

In order to make this code valid C++, an explicit cast to an int pointer must be supplied:

void* ptr;
int *i = (int *) ptr;

While it's important to understand that C and C++ are really two separate languages, it's just as important to understand that the parts of C that aren't valid C++ are extreme edge cases. C++ was originally intended to be just an extension of C (Stroustrup started out calling it C with Classes), so an effort was made to ensure that valid C syntax was broken in only a very few places. As Scott Meyer points out in Effective C++, C++ is really a federation of related programming languages: C, Object-Oriented C++, Template C++, and the STL. Almost all valid C programs will compile as C++, with very little, or often no changes necessary.

Most programmers who are deliberating between learning either C or C++ should probably skip C and learn C++. Start out with a book like C++ Primer and you will learn good programming style, not only in the C subset, but in all of the parts of the C++ language. Unless you plan on doing some work on the Linux kernel or another project that you know uses C, the only thing you will be really missing by not learning C first is Kernighan & Ritchie's C Programming Language. You can always go back and read K&R after you've taught yourself good C++ style and habits.


Further Reading

Wikipedia, Compatibility of C and C++.