bloggo ergo sum

The demons *must* be ice-skating by now.  There was an almost wholly on-topic thread on /.

The original article was an “Ask Slashdot” regarding programming languages. Below are some of the more informed comments (or so I thought), along with some of my thoughts. My apologies for not having links. I started this post using a firefox blogging plugin, and I somehow didn’t get the links included.

Don’t waste time learning a lot of computer languages. Pick one or two, learn them well, learn their standard libraries, write programs in them, and read/maintain other people’s code.

This sounds reasonable to me, but I think there are some important caveats here. I think I’d pick more than one or two languages to be in your toolbox. My preference is to be proficient in languages that fall across the following categories: statically-typed languages, dynamically-typed languages, scripting languages, functional languages, procedural languages, and object-oriented languages. Of course, there could be plenty of overlap in exactly which languages you choose. For example, my language of choice whenever practical is the C++ programming language (not “C/C++”!). C++ is a multi-paradigm language; it obviously supports procedural and object-oriented programming, but it also provides support (to varying degrees) for functional programming and generic programming (via templates and — if you can hold your nose — the preprocessor). Of course, the realities of my education required that I also be proficient in Java and C.

That takes care of the statically-typed languages. I think dynamic languages (not necessarily including their standard libraries, if there is one) are easier to learn, so why limit yourself to one? If you know C, being able to create something useful in PHP is simply a matter of learning a little Apache HTTPD administration and being handy with the PHP API. I chose to learn a little Python because it’s very useful, but also because it has some neat features and is really hot right now (which means it is gaining traction among developers and people who create tools for it, which in turn make it that much easier to use). Python has really become one of the necessary packages for a reasonably complete OS install these days. If you’ll be doing a bunch of web applications, it may be worth your while to learn Ruby; if not, then Python will be a better general-purpose dynamic language, I think. Python is very practical. There are lots of other dynamic languages out there; among the more popular are Ruby, OCaml, Lisp (and it’s dialects, like Scheme and Elisp), but don’t think it’s necessarily worth your time to be proficient in a bunch of them. Pick one or two that meet your needs.

That leaves scripting languages. The two that have been most useful to me over a number of years, and not by a close margin, are the bourne shell and sed. Of course, that gives me away as a *nix geek. I don’t have anything against Windows; I just don’t do most of my development there (and I don’t think scripting tools are as ubiquitous). I think there are very few things you could do in some other scripting language that you couldn’t do comparably using ksh99 and sed.

Update: after re-reading this, I decided to add a blurb about Perl to hopefully stem the tide of emails and comments complaining that I didn’t mention it. Fine. Perl can do everything the Bourne shell and sed can combined, plus a whole, whole lot more. It’s a true statement. Perl has incredible utility, and it’s (somewhat) portable between *nix and Windows. I just haven’t had a lot of use for it because ksh99 (or bash, as is more common) and sed take less time to learn and are sufficient to meet my needs.

So here’s the point – after the realities of my education, professional environment, and personal preferences are all accounted for, the list of languages I’m reasonably proficient in (or at least comfortable with):

• C
• C++
• Java
• C#
• Bourne shell
• sed
• Python
• PHP
• Common Lisp
• Scheme

This, obviously, is more than one or two. I suppose an important thing to remember is that several of these for forced on me by circumstance, and several of them were simply inevitable (seriously…what programmers out there with more than a year or two of experience, including school, can’t write a little bit of C?), and the rest were personal choice.

Spend most of your time focusing on concepts that generalize to all programming.

And

Knowing about design patterns is useful in any language. The intricacies of C++ template programming are not. If I say “That’s a singleton”, people will know what I’m talking about whether the code is written in Ruby, C++, Java, or Cobol.

This is certainly good advice. I think design patters can be a double-edged sword; they provide a neat little box to think in, but they can also convey the useful experiences and proven idioms of legions of programmers. It’s also simply smart to be able to take what you know and apply it in a broad domain spectrum.

However, I think it’s very, very important to be really proficient in at least one language. Don’t let yourself be such a generalist that you can’t answer a few questions about at least one of your languages:

• What are its strengths?
• What are its weaknesses?
• Does is support tail recursion?
• What 5 things would you change in your favorite language?
• If I were to create a new language that could only implement 5 features from your language, which would they be?
• Which is the best compiler?
• What can your language be practically used for?

Once or twice a year, spend some time learning about a language you don’t know. Try to understand how it’s different than the language you normally use, and more importantly why. Look at example code and code from open source projects and try to emulate their code with your code. For example, Ruby will let you open a file, read and process each line in a while loop, then close the file. But the “ruby way” of doing it is to pass a code block to the file’s “each_line” method. After you understand the syntax and the strengths of the new language, and the idioms used by the language, decide what you like, and what you don’t. Then figure out how you can apply the new things in the language you regularly use.

I like this very much, and I think it dovetails very nicely with my previous comments; doing a detailed compare-and-contrast between your most frequently-used language and a new one will help you answer the questions above, but it will also help you keep your toolbox stocked with the most useful tools for you.

More generally, languages should be treated just like essential tools are in any other profession (or craft, if you prefer). Mechanics have buildings filled with tools, each with their purpose. They have one pegboard or cabinet that contains a small set of tools that are used very frequently and those are the kind of tools that become like extensions of the mechanics’ own limbs. That’s how programming tools should be, including languages. Go ahead and get attached to one. It gives you a little personality, but don’t sell yourself short by thinking of languages as anything other than tools.