Monday, June 9, 2008

Programming Languages are Not Like the Highlander

I once assumed the constant debates over which programming languages one should learn were a sign of the discipline's relatively young age. Sooner or later, we as engineers would figure out the right tools for the right tasks and everything would eventually settle down. Recently though, I've come to another not-so-shocking conclusion: there is no universal right answer.

Language is a framework for expressing thought; computer languages are frameworks for expressing computer programs. So when it comes to programming languages, the only real advice I can give is to treat learning them like you would learning real languages. First, pick up the ones you will most likely need for where you want to be. If you want to work full time in France, you are going to need to learn French. If you want to add code to the Linux kernel, you are going to have to know C. Second, take a look at trendy languages that offer truly different features from the ones you are using. Code in Java all day? Try Python or Ruby. Never seen anything but C++? Take a look at C#. And finally, if you have the time and the desire, pick up anything that interests you or will expand your knowledge of computer science. Languages such as Erlang, Lisp, Smalltalk, and Prolog spring to mind. The good news is that computer languages are far, far easier to learn than verbal languages. Especially after you pick up the first one.

Of course, with that said, I do have my own opinions about what languages programmers should be familiar with. And since this is the Internet, I'm compelled to share them with you. My minimal list of languages you will need to know consists of the following four, presented in order of importance.

You can be a programmer without knowing C, but it's harder. C is the lowest level platform independent abstract language. If you know how to use C, you know how the machine actually works. And there is no substitute for real knowledge when it comes time to do the more technical aspects of debugging and profiling. But that isn't the real reason to know C. The real reason is every computer you will ever program will have a C compiler available.* Even if you aren't writing directly in C, it's the universal interface language. Whether you are implementing speedy libraries for Ruby or interfacing to native code through JNI in Java, C is what you use to glue the components together. Plus, you really need C under your belt before you tackle...

As a superset of C, you may wonder why I list this separately, but I believe that C++ is a whole different world than C (actually, it's about three different worlds, but that's another post). C++ is significant because it is the only widely used, object oriented language that compiles to platform native executable code at build time. Minimal startup time hits, full, explicit resource control, multi-paradigm language support, and built in C interoperability make C++ the only game in town for a huge segment of applications. Of course, that same list of bullet points makes it an extremely complicated language, full of odd edge cases and dozens of things that you just have to remember to get correct. I hate C++. But I wouldn't be as good or as versatile a programmer if I didn't know it.

Structured Query Language is how you get data into and out of databases. Databases are everywhere in our Web-enabled world, and at some point you will need to be able to access one natively. Aside from the strictly practical use, SQL is a declarative language that is a completely different style of programming than the procedural languages above. The problem with SQL is that every database vendor implements it with slightly different behaviors, and then layers on proprietary extensions. When starting out, learn the basics of the standard language and then pick up details later, when you actually work on a real project.

Any Scripting Language
A Scripting Language, for the purpose of this discussion, is any dynamic language that allows rapid development and supports batch-like automation. The leading candidates at the moment appear to be Python and Ruby, with Perl still around but beginning to fall out of favor. Again the idea here is to get a different perspective on how things can be done. A modern scripting language will give you simple regular expression support, dynamic typing, and more functional programming constructs such as closures and dynamic reflection. They are also handy for quick and dirty automation of any number of the repetitive tasks programmers often find themselves faced with.

And yes, I do pass my own requirements, but it's worth noting that I only regularly use two of the four languages above in my day job. I can even dismiss all that writing I just did. After all, if you just want to do enough to get by, picking the programming languages you learn is a practical task. You will learn the languages you learn in school because you have to be able to pass the classes. You will learn the languages at work you need to learn to either get the job or do the job. Everything else is gravy. Of course, sometimes gravy makes the difference between palatable and terrible, but I'm stretching the metaphor.

In spite of the many flame wars that erupt over which one is the best, the languages wars will never end. There is no Prize waiting for the one final immortal language to finally cut off the heads of all the other competing languages. Maybe some day the rate of creation of new languages will slow as the pace of hardware changes slows and the myriad niches of our industry settle on standard or de facto standard solutions, but we have a long way to go before that happens. And until then the languages you learn as a programmer will continue to reflect both to your peers and to hiring managers your personal choices, tastes, and drive.

* Yes, it's possible that if you work on embedded devices, you might find a custom chip that doesn't have a C compiler. However, I would bet large sums of money that if there isn't a C compiler for it, there won't be any compiler for it and you will be using an assembly language. These days that's a vanishingly small percentage of the job market, and you will still need to know C because the first application you write will almost certainly be that missing C compiler.

No comments: