Tag: ramble

  • The fallacy of the general purpose tool

    I carry a Leatherman on my belt every day wherever I go. It has become a bit of an extension of my body, which I only really notice when I have to fly somewhere and I’m forced to take it off for the flight. Then I get to my destination and I can’t open the cable ties on my luggage. At the same time, I have a whole pinboard of tools up in my garage, which overlap somewhat with my Leatherman: a dedicated set of pliers, some dedicated screwdrivers and scissors and so on. This is because the is not as good as any of these dedicated tools.

    I think the same goes for programming languages, and therefore I have learned quite a few, just like I have stocked my pinboard with tools that do one thing very well. Many people find learning new languages onerous and will try to find the one language that does everything they want to do well. Their arguments against learning a new language often involves something like “but I can do that just fine in my language, and then I don’t have to learn a new language”. Here’s an example from real life that illustrates the advantages of special purpose languages.
    My father approaches me with this problem. He uses an accounting package which can import OFX files (they’re an SGML/XML format for financial records), but there is a slight problem. The ZAR needs to be changed to USD and the dates (which are tags of the form 20111201 – yes, no closing tag as it’s SGML) have to be changed from YYYYMMDD to YYYYDDMM. Now, turns out that Python has a nice OFX module. So does Java. But the fastest way to make the changes to his files is probably sed:
    sed -r -i -e 's/ZAR/USD/' -e 's/<DT(.*)>
    ([0-9]{4})([0-9]{2})([0-9]{2})/<DT1>243/' filename.ocx

    This does the replacement in-place, is really fast and is quick enough to throw together. This is the kind of thing that sed shines at. In fact, it is exactly what it was designed to do, so it is unsurprising that it does it so well.

    To do the same thing in Python (even without using the OFX module) requires a bit more effort:

    import os
    import re
    from tempfile import mkstemp

    filename = "test.txt"
    patternStrings = ["ZAR", r"<TD([^>]+)>([0-9]{4})([0-9]{2})([0-9]{2})"]
    replacements = ["USD", r"<TD1>243"]

    # Compile patterns
    patterns = [re.compile(p) for p in patternStrings]

    # Create temporary file to hold outputs
    _, tempfile = mkstemp()

    # Process file
    outfile = open(tempfile, 'w')
    for line in open(filename):
    for pattern, replacement in zip(patterns, replacements):
    line = pattern.sub(replacement, line)
    outfile.write(line)

    outfile.close()

    os.rename(tempfile, filename)

    Needless to say, the difference is even more pronounced in Java due to the large amount of boilerplate needed.
    import java.io.File;
    import java.io.FileReader;
    import java.io.FileWriter;
    import java.io.IOException;
    import java.util.Scanner;
    import java.util.regex.Pattern;

    public class Fixer {
    static File infile = new File("test.txt");
    static String[] patternStrings = {"ZAR", "<TD([^>]*)>([0-9]{4})([0-9]{2})([0-9]{2})"};
    static String[] replacementStrings = {"USD", "<TD$1>$2$4$3"};

    public static void main(String[] args) throws IOException {
    Pattern[] patterns = new Pattern[patternStrings.length];
    Scanner in = new Scanner(new FileReader(infile));

    // Compile patterns
    for (int i=0; i<patternStrings.length; i++) {
    patterns[i] = Pattern.compile(patternStrings[i]);
    }

    // Create temporary file to hold outputs
    File tempfile = File.createTempFile("tmp", "tmp");

    // Process file
    FileWriter outfile = new FileWriter(tempfile);
    while (in.hasNextLine()) {
    String line = in.nextLine();
    for (int i=0; i < patterns.length; i++)
    line = patterns[i].matcher(line).replaceAll(replacementStrings[i]);

    outfile.write(line + System.getProperty("line.separator"));
    }
    outfile.close();

    // move temp file back to filename
    tempfile.renameTo(infile);
    }
    }
    Now, at this point someone is bound to say “but wait, people don’t write desktop apps in sed!”. But that’s quite the point – Java was designed with programming in the large in mind, but it is really tedious for short programs. In many cases, learning a small domain specific language and using it to solve your small problem is faster than learning how to do the same thing in your “one language”.
    I wish I had more time to put examples together, but this situation just presented itself and got me thinking.
  • Factors to consider when choosing a programming language

    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).

  • Programming language pragmatism

    So, it appears as though I have broken my long GUI drought by writing my first functional Mac OS X app in Objective C. In the process I have also discovered why GUI programming used to be so easy for me when I was younger: I was less picky. The app I have written is a really small thing that calculates pace and speed. However, the amount of duplicate and ugly code in there to get it to work is mind-blowing after having spent some time programming in more dynamic languages.

    I guess a part of it is that I don’t know the language very well, but a lot of it is just that Objective C is a very small extension of C, and that lacks the kind of mechanisms I have become used to. In another post, I’ll elaborate on how the different languages one uses informs how you think about programming as an activity. I am definitely feeling the blub effect (read that link – it’s really worth it), in that I’m missing a lot of features from other languages in Objective C.
    The other interesting thing I’m noticing is how the tool (XCode) that you use to program is a part of the programming experience. I am discovering first hand how little many people feel the pinch of verbosity in their languages due to good tools. Even though this article is pretty old, I still feel it rings true. In the language of that article, I am a language maven rather than a tool maven. When I start learning a language I imagine writing code in a simple text editor. It’s then that typing and elaborate method names really seem like they’re a pain. In an environment that automates a lot of that stuff for you, you’re less aware of the language and more of the overall tool experience. I still can’t say that Objective C is a beautiful language, even with XCode. But then, I’ve never been a fan of the curly-brace languages in general other than a couple of years of loving C when I was in high school. I’ve kind of migrated to languages that scan more like spoken language.
    Well – no-one said that blogging had to be deep all the time right? What do you guys think about the language vs tool debate? Just to get things started, I’ve noticed that most of the people who absolutely love static typing are tool users. Static typing makes the tools more useful, as they can figure out the types of things while you’re typing and suggest completions of methods and so on. Obviously this is significantly harder for dynamically typed languages, so the tools seem much less capable. Maybe I should learn more tools.