Learn Another Language

There are a lot of computer languages out there. Each one has vocal adherents. They often sound like the folks who used to battle over whether the Commodore 64 was better than the Atari 800. The fact is that computer languages are created for a reason, they're created to solve a problem. Each one has its own features, and its own approach to dealing with specific problems that the implementors saw with existing languages.

Learning a computer language is an involved process. Learning modern object-oriented languages well enough to be well rounded in all their features is a time-consuming process. I'd say it takes two years to become competent, longer to become really good at solving any arbitrary problem with the language. With this kind of a time investment, why dilute your efforts by learning more than one language?

I took English classes all the way through elementary school. I got good at spelling, and developed a pretty good vocabulary. But most of the grammar went right over my head. In 7th grade I started taking a class in German. Suddenly all this stuff about subjects, objects, and indirect objects started to make sense. It was enough to make me wonder why I'd never gotten it before, it seemed so simple.

The same sort of revelation can occur when learning a new computer language. Concepts that were muddy before can suddenly be illuminated by the new language. This is especially true when learning a language that's been designed for an entirely different class of programs than your first language.

The "big" languages today are far more flexible and more generally applicable to a wide range of problems and programming approaches than the simpler languages of 30 years ago. This is part of why it takes longer to learn them thoroughly. They've adopted the good parts of many earlier languages, usually building on a base of a strong prior language. The result is that it can make each language look like it's the be-all and end-all of languages. They fill a lot of checkboxes, and even where they don't have a specific feature, they have some other fairly direct way to get the same results.

This doesn't mean they're all the same, however.

Why Spend the Time?

Still, there's only so much time and energy. With learning a language being such a substantial undertaking, why divert effort into a new language rather than delving deeper into the one you already know?

First, diversification is not only educational, it's a survival skill. Overcommitment to one language means that when the need to shift finally comes, it'll be that much harder to change one's thinking to adopt a new language effectively. Languages will change, new languages will appear that will overshadow current languages. Current languages aren't likely to go away--code tends to hang around--but new languages will dominate. Even if you still work with an older language, understanding newer languages and what they do will be valuable to you. Chances are your language will change and adapt, too. A prior understanding of the new concepts will make it that much easier to take advantage of these changes. Either way, you'll be a more valuable programmer.

And it will be easier to learn the new languages if you are already familiar with several. Those new languages are going to come from somewhere, and if you've already got a regular approach for picking up new languages, you'll just be applying it to yet another.

Educationally, there's more to learn by picking up new languages than the new syntax and programming constructs. Learning a new language often means learning to work in a new development environment, and possibly with a very different workflow. You'll have a chance to see what other programmers use, and see the advantages. Perhaps the same features are already there in the IDE you use with your own language, you've just never been motivated to try it out since you didn't perceive the advantage. Each different language tends to have a preferred set of tools for version control and project management, too. Even if you only ever program professionally in one language knowing more than one toolset for everything from editing to distribution is of tremendous value.

There's nothing worse than knowing the language that everyone is advertising for then get passed over for job after job because you don't have experience with the employer's environment.

If you're a lone wolf developer, or part of a small team, knowing more than one thing is even more important. It's essential to get as much productivity as possible out of the few work hours available. You can't afford to spend your time carrying water from the well in buckets, you've got to put in plumbing to be productive. If you don't get out of your groove and look around at what other languages and other toolsets have to offer, chances are you're carrying buckets and complaining about how there's no time to put down the buckets to learn plumbing.

Picking a Second Language

Choosing the language to learn is important, too. It shouldn't be over-thought, however. It's not like it's the last language you'll ever learn. You can also break off and change choices at any time, though it's best to stick with one long enough to get well enough in to understand why it does things the way it does.

For your new language, you may want to pick a second language close to the one you already know. This can be both good and bad. It can introduce you to some new things without requiring as much of a change of pace as a totally unrelated language. The problem is that you're not getting as far out of your groove as you would with something else, and the syntaxes of two similar languages might just get jumbled in your head making it even harder to use your primary language.

Picking a language that's out of left field for you will require more effort to learn and understand, but it avoids the problems of picking a closely related language.

One way to diversify is to select a language that's of a different scope than your current language. If you're programming in one of the more "full-up" languages OO like C++ or Java, you may want to pick up one of the "scripting" languages like python or ruby. Or you can take a step even lower to the actual scripting languages like one of the Unix shell languages (ksh, bash, csh, etc.) If you already know one of the simpler languages (whether simpler in features or in syntax--I don't mean any of these comparisons as value judgements) you should probably give a try to something more involved.

There's also diversification in terms of language type. This relates to the approach the language takes to solving problems, and the mindset used with the language. If you know a procedural language, try a functional programming language, perhaps. If you're not doing object oriented programming, try one of the OO languages--particularly one of the OO scripting languages.

If you want to limit your efforts, there are a lot of languages that you can learn without too much effort--at least well enough to get a feel for the language's approach. Clearly the syntax-light "scripting" languages fulfill this requirement. But other languages, such as LISP and LOGO are also very easy to learn, and they're often well off track for most programmers relative to their usual language, making them a great learning experience. I know that LISP and its related languages are going through a bit of a vogue right now, my recommendation has nothing to do with that. I've been recommending LISP since I first learned it in a single quarter's class in 1981. And though LOGO is often considered a "kid's language," I personally consider it more of a LISP with a lot of the historical cruft taken out. Either way, the current vogue of LISP-y languages is a good thing. It means there are many good, modern implementations and tool sets for them.

Forth is also easy to learn, and playing with its guts is both fun and educational. You don't necessarily have to join the religion. ;)

Assembly programming is not as straightforward as it once was, interactions with modern OSes make it more involved. However, learning assembly using a virtual machine of some sort, solves this problem. There are free, downloadable development and simulation environments for many microcontrollers. This can be a good way to get started with assembly.

If you only know one language, get out and learn another. It'll be fun, it will stretch your brain a bit, and it'll make you a better programmer, even in your first language.