Not all languages are created equal

I spent the better part of yesterday (and an hour today) on my C++ project for class. The project itself is pretty simple: Read in a file that contains descriptions of cars in a specified format, convert it to some sort of internal database and then allow for simple queries and purchases. I’ve probably spent about a total of roughly 6 hours on the project which includes teaching myself about C++’s string streams and standard template libraries, learning about operator overloading, the use of consts and writing Doxygen-compatible comments for my code. I still haven’t written unit tests for it.

6 hours isn’t much as far as a college-level project is concerned, but I can’t help thinking that if I’d been using a language like Python or Perl I could have done it all in about an hour. I’ll be using C++ for a longer semester long project where I’ll be building a not-too-complicated as part of a team ,but I can’t say that I’m really looking forward to it. C++ by itself isn’t a bad language, and there are some really nice toolkits built around it (Qt for example). But given a choice, it would not be a language I would use.

I’ve spent the last two years exploring a wide variety of languages from C and C++ going up to Lisp and Prolog and exploring ones like Java, Python and ML in between. I’m far from being experienced in any of them (except perhaps Python), but there are a number of things I’ve learned about languages that I think are worth sharing.

1. Languages are tools. No more, no less.

I find myself lucky to be at a college which is certainly not a Java School, in fact Java isn’t really used much beyond the intro courses. We use a wide variety of languages and the one of the things I think that our professors are trying to teach us (even if they don’t say it explicitly) is that languages are simply tools. Like any tool, you should use the best one for the job. Of course, there is a certain amount of personal preference involved in choosing the right tool. This in turn brings us to point #2.

2. Learn as many as you can.

Now by “learn” I don’t mean “become an expert at”. I mean use it enough to know what problem domains the language in question applies to. Functional languages aren’t the best for describing complex data structures and business logic and you probably don’t want to do a lot of string processing in C. The best way to get this kind of experience would be to do a major project in each new language you learn (something you can easily accomplish in under a month working on your spare time).

3. The industry standard isn’t always the best.

By and large, the industry standard today is C/C++ and Java. They aren’t bad languages, but they certainly aren’t the best either. A simple search for C++ sucks or Java sucks will turn up ample amounts of pain. However, if you want a job as a programmer you’re going to need to know these. That being said, it doesn’t mean you shouldn’t keep your eyes out for something better. Viaweb (which later became Yahoo! stores) was written in C and Lisp. So were the first versions of Amazon. Google uses Python a lot, especially for its App Engine. Languages like JavaScript and PHP are becoming core technologies of the web. If you stick to the industry standard, there’s a whole world of goodness out there that you’ll miss.

4. When in doubt, choose expressive power.

When starting out a project, it can be an interesting question as to what language to use (unless you have a mandate from up high). The way not to make this choice is to look at what others are using. You should try to use the language that makes it easiest to express your problem and it’s solution in the most straightforward way. In many ways this the tools argument in another form. Coming back to my project, I would have used Python to write something like that since it gives good data structures and easy to use string processing. On a wider scale this means that for the most part you want to avoid non-memory managed environments wherever possible, because memory management inevitable distracts from the higher level algorithm you’re trying to implement. Java for all it’s niceness and industry strength, isn’t very expressive due to a number of really bad design decisions that it’s too late to correct.

5. Read the manual

It can be surprising how many people will start railing and ranting at some language or language feature without properly informing themselves first. A lot of the times it can seem as if the language you are using is quite simple getting in your way. For a good few weeks I thought that way about C++, especially in regard to string processing. However, reading the documentation and tutorial about your language can make a world of difference. In particular knowing about the libraries that are available and reading some example code can make a world of difference. For me, the aha moment came when I learned about string streams which made my job a lot easier. I stilll don’t think it’s very elegant and it hasn’t made me love C++, but it has eliminated a source of complaint and let me concentrate on solving the rest of the problem. (And I’ve been convinced me that yet another C++ rant is uncalled for at this point.)


Published by

Shrutarshi Basu

Programmer, writer and engineer, currently working out of Cornell University in Ithaca, New York.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s