I firmly believe that a programmer must know several programming languages well in order to be top-notch. And the less similar these languages are, the better. The reason for this is that different languages often present different programming philosophies - different approaches for solution of problems. Being acquainted with several techniques to solve a single problem makes it easier to solve the problem in an optimal way.

Additionally, my philosophy in programming is that no single language / methodology is good for everything. Some languages are better than others to solve specific problems, and an experienced developer must know when to use “the best tool for the job”.

I am programming computers non-stop since late 1998. Below is a description of my current programming language “arsenal”. Namely, the languages I am most familiar with.

C / C++

C was the language I began programming in, and is still the language I know the best. The reason for this is C’s simplicity. It’s a small, easy language to learn and to master. For the vast majority of applications, however, C is too simple. C’s focus is on performance, and hence it lacks modern abstraction mechanisms, which makes C programming much more wordly and tedious than contemporary “high level” languages like Perl and Ruby.

C++ is its older brother and a much more complex and sophisticated language. C++ is a very difficult nut to crack, mostly because it combines complex abstraction mechanisms with terrific performance (if C is the measurement criterion set at 1.0, C++ has performance that’s rarely worse than 1.1). I know C++ quite well, but far from the total knowledge I have of C, for instance. In fact, I know only a handful of people who really know C++ perfectly. If you think you’re one of these people, try reading Alexandrescu’s “Modern C++” for a harsh return to reality.

These days I rarely use C / C++ for “desktop” coding. I still use C heavily for programming embedded devices, where it really is the only real option. But on PC’s (where code runs on top of full operating systems like MS Windows or Linux), C / C++ is simply inferior to other languages in terms of programmer productivity, which is a very important factor these days. Whatever I can write in C++ in a day I can write in Perl in a couple of hours. The only occasions I turn to C++ are when top performance or a low-level interface to the operating system or a third-party library are required. But even in these cases, the C++ part is usually encapsulated as a small library with the main Perl code controlling it using one of the many interfaces available. I had both linked C code to Perl for performance, and used a stand-alone C++ program connected to the main Perl script via a socket for accessing operating systems internals.

Perl

Perl is my main tool at the moment. Criticisms of Perl are numerous, and many of them are true, but whatever they say, Perl is a productive language. I know I can write good and useful code in Perl that accomplishes the tasks I have satisfactorily. Perl enjoys an enormous collection of ready libraries for any purpose - the CPAN, a very mature base of documentation and literature, and the best programmer community (by a mile) one can find (Perlmonks). However, Perl is getting old and some of the most advanced programming idioms take some teeth screeching to implement. OO in Perl 5 is a known fiasco (no matter how many Class::* modules they throw at you) and functional paradigms lose some of their charm because of the clunky syntax. While there is currently no language better than Perl to solve specific problems “at hand”, superior languages exist when it comes to writing big systems.

Ruby

Ruby is the best candidate to replace Perl as my “main tool” in the future. I just discovered it this year, and so far I’m charmed - and I try to write all my new “toy project” code in it. Ruby is everything Perl is and more. Language-wise, Ruby allows the same level of productivity and ease of programming as Perl, and adds a lot on top of it. Much cleaner syntax, an excellent OO system and even better tools for writing functional code. If there is a potential Perl-killer in the world, Ruby is it. Even Perl 6 won’t help here, because although it cleans Perl up and fixes some of its gravest deficiencies, I can’t fail noticing that it still looks inferior to Ruby 1.8 in many aspects, and Ruby 2.0 will be even better (and will arrive earlier than Perl 6). The best thing about Perl 6 is, IMHO, Parrot - from which Ruby will also benefit.

Ruby is not without problems, however, which is mostly why I still use Perl for most of my serious coding. The documentation is far worse, the community is much smaller and much less powerful, the libraries are incomplete and immature (and many have only Japanese docs and home-pages). The threads implementation is very weak and the GUI bindings are nowhere as polished out (Perl TK maybe isn’t the prettiest and the simplest library in the world, but you can create complex and useful GUIs with it, right out-of-the-box).

Ruby is also slow. Though compared with C++, Perl isn’t exactly the king of speed (it is on average an order of magnitude slower), Ruby is much slower than even Perl (x5 or so, according the the Shootout benchmarks and other sources). This isn’t a very big problem, because critical sections can still be written in C++ (for which Ruby has good bindings), but still I wish it could be faster, at least as fast as Perl, say.

Lisp

Lastly, I must mention Lisp, which is probably the most controversial language out there (it seems that people either love or hate it, without much in the middle). Although I don’t use Lisp for any real coding and unlikely to do so in the future, Lisp has taught me a lot. I feel that learning Lisp made me a much better programmer, and for that I will be forever grateful. As Eric Raymond famously noted:

LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot.

What Lisp “teaches” is the functional programming style, which is IMHO the cleanest and the most elegant way to program.

Conclusion

Don’t stick to just one programming language, even if you like it a lot. Besides looking bad on a resume, knowing only one language will lock you in a very narrow point of view on the world of programming. Learning and knowing well at least 2-3 different languages is essential to become a much better developer.

Related posts:

1. “Progamming language choice and calibre of programmer”
2. Programming language typing - a big mishmash
3. DSL = Metalinguistic Abstraction
4. Book review: “Programming Ruby, 2nd Ed.” by Dave Thomas and Andy Hunt
5. Book review: “Ruby Cookbook” by L. Carlson and L. Richardson

This entry was posted on Friday, August 11th, 2006 at 12:09 pm and is filed under Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.