Choosing a Programming Language

This article was originally written for iDevGames and CreateMacGames (no longer in existence), but I'm republishing it here as a complement to my "Why not C++" post. It's not exactly what I'd say today (Haskell's a lot harder to master than I make out, and a lot better at I/O than I make out) but I think it's still a good read.

Like Moths to a Naked Flame

An oft-asked question by beginner programmers is, "What language should I use?". The answers that are given vary, but usually involve heavy recommendations of C and C++. And that's where it stops. The student learns the recommended language, and never stops to consider what else they might learn.

Time passes, the bright-eyed student becomes something of a guru herself, and when it comes their turn to answer the inevitable question for the next generation, she's hemmed in by her own experience. "C or C++", comes the stern reply, and another generation marches blinkered toward the same fate.

Why must this always be the case? Why is it so difficult to leave the beaten track? Why, when it comes time to start a new project, is the question always "How can this be done in C++?", rather than "What language would make this project easier?"?

Why Computers are Better than People, Reason #457

The point many people miss, here, is that computer languages aren't like human languages. It might take you a lifetime to master Japanese. You're looking at maybe a week for Python. One week to mastery. Not "good morning" and "my name is Ellie" clumsy beginnings; not even mere competent conversation; we're talking complete, total and utter mastery.

Pick a difficult language, say Perl, and we might be in two-week territory.

How about a completely different paradigm; a whole new way of thinking? It shouldn't take a month to master Haskell.

There's no reason to limit yourself by the languages you know — the effort to acquire a new one is miniscule, while the pay-offs can be tremendous.

On Round Pegs and Square Holes

Every new project gives the opportunity to start afresh; to reevaluate preconceptions; to apply knowledge gained during the execution of the last. The choice of a programming language is no different.

The decisions made now will have a profound impact on the outcome of this latest venture. The choice of language(s) will affect how easy it is to produce the program in the first place; it will affect how easy it is to modify the program later; it may even affect how easy it is for the program's users to customize your program to their liking. Why ignore the choice given you?

People don't like to ask the difficult questions. The questions like "Why are we using C (a language for writing high-performance code) to create a desktop office suite (where performance requirements are very low)?". The questions like "Why are we using Java (a language for writing high-level reusable code with low performance requirements) to write a software 3D renderer supposed to run in real-time?". The questions like "Why are we using Haskell (a language good for complex mathematical computation, but poor at I/O) to write a file-format translator?". The questions like "Why are we using Perl (a language good for text-processing) to write an image-editing program?".

Would you fire your builder if she tried to drill a hole in your wall with a spanner?

Choosing the Right Tool for the Job

Every language has its strengths and weaknesses; it has areas where it particularly shines, and areas where you'll only be fighting the language to try and accomplish anything.

When you start your next project, stop and think for a while. List the requirements you have for your programming language, and match them up against actual languages. Chances are you won't find an exact match, but this should help focus your attention on a small group of languages that are more suited to your task than the others.

Color-Coordination; or When a Track-Suit isn't Enough

One problem you've likely encountered having followed the advice of the previous paragraph is that different parts of your program have different requirements. If you're writing a game, for example, you'll probably have a large portion of your program (containing AI, game logic, user interface, &c.) which needs to be easy to build and easy to change, but where performance isn't critical. Unfortunately, you'll also have a small, hard core of the functionality (probably graphics and physics routines) where performance is of the utmost importance.

As with clothing, not everything has to be the same color. As with food, you're allowed to have more than one flavor in a meal. In programming, you don't have to use the same language throughout the entire program. There are ways and means of embedding almost all languages in other languages, even if it involves going via C on the way. This way you can enjoy the benefits of each language in the areas suited to it, without succumbing to its weak areas.

Beware the fashion police, however — too many different languages in one project will quickly tie you up in the mess of integration, rather than letting you get on with using your chosen languages. I still have visions of my high-school English teacher, whose favorite color combination was yellow, lime green, turquoise and hot pink. You don't have to be like her!

Forging a New Path

Take off your blinkers! Look around you! Marvel at the vast array of possibilities! Dare to find the language which makes your task easier!

And when you, in turn, get asked "Which language should I learn?", do the right thing — ask a question in return: "What do you want to create today?".