Negative Feedback

Factors to consider when choosing a programming language

Written by

alchemyst

in

This morning a colleague and I spoke briefly about choosing a programming language for some high-performance scientific computing (thermodynamic calculations) he wants to do. I started writing an e-mail with a couple of my thoughts, and then thought it would make a pretty good blog post for the same amount of time. So here’s my list of things to consider when choosing a programming language. Note that these are not orthogonal to one another – many seem to describe the same thing from different angles. This is just my musings, not a research study.

  1. Popularity. This is a very important one. A good place to start is the Tiobe index. You are more likely to find people to collaborate with if you use a popular language. You are also more likely to find reference material and other help. Unfortunately, the most popular language globally may not be a good match for your problem domain.
  2. Language-domain match. Choose one that matches your problem domain. You can do this by looking at what other people in your field are using (after adjusting for popularity, so don’t think the match with Java is good simply because a lot of people are using Java) or by looking at some code that solves problems you are likely to have and seeing how natural the mapping is.
  3. Availability of libraries. Some would argue that this is the same as the point above, but I don’t think so. If there’s a library that solves your problem well, you’ll put up with some ugly calling conventions or hassle in the language.
  4. Efficiency. Languages aren’t fast – compilers are efficient. Look at the efficiency of compilers or interpreters for your language. Be aware that interpreted code will run an order of magnitude slower than compiled code as a rule of thumb.
  5. Expressiveness. The number of lines of code you create per hour is not a strong function of language, so favour languages that are expressive or powerful
  6. Project-size. Do you want to be programming in the large or programming in the small? Choose a language that supports your use case.
  7. Tool support. Popularity usually buys tool support (and some languages are easier to write tools for). If you are a tool-oriented user, choose a language with good tool support. Just read this article on tool mavens vs language mavens before you make a choice.

Note that all these things have no single right answer: they define the languages on my Pareto front. A good starting point to observe the trade-off between expressiveness and efficiency is the Computer Shootout. Also check out this analysis of some of the results.

Of course, a personal blog need some personal input, right?

I happen to know many languages, and the combination I use at the moment is Python for prototyping and Fortran (2003) for speed. Python is popular (it’s the second interpreted language on the Tiobe index, after PHP, which sucks for scientific stuff). It’s got a really nice set of libraries for the jobs that I am doing now and makes wrapping Fortran code easy. Fortran has some really good compilers (and the free gfortran is pretty good), and suits matrix-oriented programming really, really well. YMMV

Both of these languages have good tool support in Emacs (my favourite text editor) and Eclipse (which I am slowly picking up).

Comments

3 responses to “Factors to consider when choosing a programming language”

  1. the SA Critic Avatar
    the SA Critic

    Interpreted languages are not always that much slower because of JIT (Just in time compilation), but in general that would be true.

    Also I would not rank expressiveness/brevity at the expense at readibility, maintainability and ease-of-understanding.

    Domain matters – but I don't believe so much for the language, as for the library functions.

    Even if a language doesn't offer direct support for expressing problems in an abstract symbolic notation (e.g. functional notation or logic programming), a language with nothing more than string support and OOP, but with an extensive symbolic manipulation library that operates on strings, would get the job done pretty much as well or better than the domain specific language that lacks the extensive libraries.

    So I think if you have to chose between libraries and language features, the library can become the determining factor if the library functions are a good fit to your problem domain.

    var f = newFunction("add",newSymbol("X"), newSymbol("Y))
    var result = doSymbolicDifferentiation("X",f);

    is not that much inferior to

    (deffun f (+ X Y))
    (let result (doSymbolicDifferentiation X f))

    Reply
  2. Carl Sandrock Avatar
    Carl Sandrock

    I am constantly amazed at how quickly interpreters are becoming more efficient. Looking at those computer shootout results, LuaJIT is really kicking ass these days.

    Thank you for mentioning readability – I should have put that on the list! It is very important to me.

    About the domain-language match, just take your symbolic examples and think about doing "diff(x+y, x)" in Maxima. The fact that Maxima supports this, makes it far more likely that you'll do something like ans := subst(y=3, solve(diff(f, x), x)). If you have a symbolic problem you may think of downloading the library, learning the methods etc, but it's more likely that you'll do something that the language makes easy, because that's what programming is – using the language to solve the problem you have.

    Of course languages can do what other languages can do, but if you program in Smalltalk you see everything as objects, if you program in Matlab you see everything as matrices – it's very seldom that the "real problem" is already stated in programming terms, so there's always the question about how you break the problem down, and the language forms the way you think. So I'm not talking about the language supporting the way you wanted to work before you learned the language, but rather the language matching the problem domain so that you learn both together.

    Reply
  3. Carl Sandrock Avatar
    Carl Sandrock

    PS (and off-topic a bit) check out Sage http://www.sagemath.org/ for a good example of good integration of libraries with Python can make it feel more like a symbolic environment. It kindof proves my point, because I find it much more clunky than Maxima for quick symbolic manipulation – that's the overhead of not having started the language design with symbolic computation in mind.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

More posts