My thoughts on programming languages

I've done most of my programming work using C/C++ and Java, with some Perl, Python and Ruby thrown in. My favorite language to date is Ruby, although I only use it occasionally. TIOBE rates the popularity of programming languages.

The The Mythical Man-Month is a book about software development process, and it explains why I enjoy programming, and why I often find it tedious.


Ruby

An excellent book on Ruby is Programming Ruby by Thomas and Hunt. These authors introduced me to a fun, powerful, object-oriented scripting language. Their book is online at Ruby Central. An enjoyable introduction to Ruby is why’s (poignant) guide to Ruby . Ruby code is easy to write, read and maintain. Read the preface to Programming Ruby -- it explains why Ruby is an amazing language.

Useful applications and modules for Ruby can be found at the Ruby Application Archive.


Perl

In Perl, there is more than one way to do things. It has some advantages over Ruby: it is nearly ubiquitous, more programmers know the language, and CPAN is expansive.

Perl code can be difficult to maintain. Its object-oriented syntax is extremely ugly. I'd much rather maintain Ruby or Python code than Perl code, as a general rule. Perl 6 may solve the maintainability problem and make it a more syntatically clean object oriented language.


Python

Python is attractive because it looks syntactically clean (unlike Perl). It's popular and easy to maintain. Ruby is also clean and maintainable. One thing that I dislike about Python is its lack of inline regular expressions. I use regular expressions frequently in Perl and Ruby.

Sometimes, I find myself fighting against Python, instead of flowing with it. Ruby is a language that works pretty much like I would expect -- it doesn't surprise me or frustrate me.


Java

I like Java. It has powerful libraries, is easily maintainable (much easier than C++), and there are great tools (especially IDEs) to help programmers use the language. It is somewhat cross-platform. Unfortunately, sometimes the same code that works with one point release of the JRE will break on another point release.

My gut feeling is that Java offers programming teams at least a three-fold increase in productivity over C++. Memory bugs are rarely an issue. Java doesn't hide behavior from programmers, because it doesn't support operator overloading (I think this is usually a good thing). The libraries are powerful, well-designed (not perfect), and keep programmers from shooting themselves (or others) in the foot.

Java doesn't run on as many operating systems as it should. In my opinion, Sun should open-source their implementation of the JVM and the supporting libraries, and let the world port it to every operating system known to man (they could dual-license it so they could still sell it). I think that this is vital to increase popularity and adoption of the language.


C# and .NET

Some of my colleagues use C#, and they like it better than Java because 1. Microsoft's IDE makes it incredibly easy to develop applications (I'm told that nothing rivals it, especially for building robust web sites), 2. the CLR runs significantly (10x) faster than the JVM, and 3. the language designers learned from some of the mistakes with Java.

C# and accompanying libraries are available for Linux/UNIX from the mono project, and come by default with SUSE linux. Some people fear patent problems cropping up with Mono from Microsoft (since they've got a track record of being anti-competitive).


C/C++

I like C++ and even C, yet sometimes I hate maintaning programs written in C, and to some degree in C++. Memory management bugs are a waste of time. I am glad that the STL exists, but I still feel like the standard libraries are underpowered in this day and age where other language libraries are so rich. Somehow I still enjoy programming in C and C++ because it allows me to work at a lower level than many other languages. Unlike Java, C/C++ allows programmers access to operating system calls and services.

C++ programmers should be aware of the excellent BOOST libraries.


Shell Scripting

UNIX shell scripts can be very handy, powerful tools. Certain languages, like Perl, are a natural extension of shell scripting. Bash and ZSH are my two favorite shells, followed by ksh and sh. Windows batch files are severely limited in comparison to UNIX scripting languages.

Shell script resources:


GNU Make, Ant

Make is a tool to help manage the dependencies of compiling programs. GNU Make is the best quality version available. Microsoft nmake leaves much to be desired (especially in the way of documentation). The standard version of make that comes with most commercial versions of UNIX is underpowered.

Ant is a make-like tool for managing java projects. It is an outstanding tool, although it has its quirks.


Regular Expressions

Regular expressions allow a programmer to easily match, parse and replace text using a very compact representation. They can save a programmer hours of work. Many modern programming languages support regular expressions. And for those that don't, libraries are available (PCRE, BOOST). Read my summary of regular expressions.


Assembly

If a programmer really wants to understand what is happening in a computer, then it is useful to learn assembly. It's also extremely useful in order to gain an in-depth understanding of shell code security exploits.


Learn how to Program (May 2002)

Do you want to know how to learn how to program? There was an "Ask Slashdot" about Conceptual models of a program. People talked about various books that are somewhat timeless (I.E. less prone to hype, and won't go out-of-date anytime soon). Here is a list:

Structure and Interpretation of Computer Programs (heavy reading -- but likely quite good. I took a class at BYU that taught this using scheme -- I was quite impressed).

How to Design Programs. Mentioned several times -- looks very good. See the table of contents

ANSI Common Lisp by Paul Grahm: http://www.paulgraham.com/

How to think like a computer scientist (if you want to learn Python): http://www.greenteapress.com/thinkpython.html (I briefly took a look. It isn't as good as the one at htdp.org. And I dislike Python. Ruby is much, much, much more elegant).

Pragmatic Programmer (I've got this at work -- it's a good book, but doesn't teach programming -- just pragmatic approaches to it). I really liked it.

Design Patterns by 'GoF' (meaning gang-of-four authors). I've read this one too, and it is somewhat heavier than you might want. It's a book that you read after you know how to program. The ideas/approaches to solving certain classes of problems are good. The difficult part is knowing when to apply the "patterns" in your program, and to not over-use them. Patterns are NOT everything, and can make programs too complex if used wrong. See this funny example.

The Art of Computer Programming by Knuth (three or four volumes). I've heard that these are _very_ good, but I've never read them.

I have included some posts about these books below.

----

I feel like Paul Graham [paulgraham.com]'s "ANSI Common Lisp" is more fun to work through (and makes my brain hurt somewhat less) than SICP. SICP is a really stiff book -- using that text for a class is a sure way to weed most people out. Graham's book, while very very intelligent and deep, is also a lot easier to grasp in many respects. Not a bad choice for 'SICP Lite' although that doesn't give it enough credit for what it teaches you about programming in the real world (vs. the computer-linguistics and mental gymnastics that SICP teaches you).

(Read the articles on Graham's site. They're friggin' amazing distillations of experience. If you've been programming (successfully) for long enough, you'll not only be pleasantly surprised, but will find yourself nodding in agreement whilst learning about new topics.

----

Structure And Interpretation of Computer Languages

The granddaddy of this type has to be MIT Press' SICP. It's a programming intro, but it teaches you lambda calculus as well as the problems with lambda calculus.

Lambda isn't everything, and a good teacher should also cover some languages which use it lightly (J and K) as well as a language which doesn't use it at all (Forth, Postscript, Joy) -- but it's good to have as a starter. SICP doesn't teach 'conceptual models', though; I don't think that the authors even realised there were other conceptual models out there. Most people don't, since most people don't even know that lambda calculus has almost nothing to do with how computers work, but is rather just the way most programming languages have been designed, in imitation of Fortran.

But I can't slam SICP. It may not cover other conceptual models, but it does a BANG-up job of covering the one it acknowledges, and even points out the weaknesses.

----

Sidenote on Coroutines: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html


Return to my home page.