Negative Feedback

Year: 2010

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

  • What does “it works” mean?

    Response to my rants about the hologram bracelets and articles like this one about magical thinking on SciAm have forced me to re-evaluate my language. I would like to say that the hologram bracelets “don’t work” because they have no physical effect on the phenomena that they claim to affect. However, people who use the bracelet will probably have a measurable improvement in their performance as per the SciAm article. So what to do?

    Ever since reading Ben Goldacre‘s Bad Science, I’ve been fascinated by the term “no better than placebo”. The placebo effect is one of the reasons for using blind testing and shows what kind of rigour needs to be employed to avoid being fooled. Now, the idea is that a medicine is only really effective if it works better than placebo. Is there a corollary that says that if a medicine will not be particularly effective, it is better to attempt placebo treatment? I suppose this makes a kind of sense if the medical solution has physical side effects but the placebo doesn’t. I just can’t bring myself to think that I should start believing in crystals and holograms so that I can have cheap placebo improvements to my performance. Is this why superstition persists? I suppose it should be no surprise that it would have been selected away unless it conferred some advantage.

    Unfortunately this brings us to an uncomfortable point. If the superstitions really do confer advantages (even if only mental) what is the sceptic’s method of achieving similar benefits for similar (low) cost? It costs nothing to wear gold thongs to important interviews – what should you do if you honestly don’t believe the thong will work? In fact, what does “work” even mean in this context? I hate semantics.

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

  • Dogma and change fatigue

    There is never time to do it right, but there’s time to do it again. Use the right tool for the job. If it’s worth doing it’s worth doing right. These are some items of dogma that I have lived by, and they are making me unhappy and a bad worker.

    Many people have described me as an idealist. I have also recognised a certain evangelical streak in myself. Combine this with the values described by the phrases above and you have a recipe for Quixotic enterprise. This idea of using the right tool for the right job seems quite simple, but there’s a hidden catch: what is the right tool? What is the right way to do something? When you really hold on to the dogma of “Do stuff right using the right tools” you are setting yourself up for a lot of pain. You start searching for better tools (to make sure you’re using the “right” one), you start searching for better ways of doing things (to make sure you’re doing it “right”) and you eagerly evangelise the latest thing you’ve learned as the answer to these questions.
    Of course, somewhere in the back of my mind I know the whole idea is bogus. I guess I was a bit happier when I knew less methods of doing things. Not because I was less enamoured of the dogma above, but because I was more convinced I was doing things right. Looking back, I find myself thinking I was doing things all wrong. So how was I able to be so productive? Because the dogma is wrong, or at least wrong when you interpret “right” as “best”. The idea that there is only one right answer to vague questions like this is of course pretty immature. I am learning now how coupled the idea of “right” is to what you know, your skill level and the greater community. Perhaps I should try and focus on getting stuff done using what I have, and looking at projects that have actually delivered results for me, that’s pretty much what I had to do.
    But this brings me to the change fatigue part of the title. Once you realise that you should be freeing yourself from dogmatic adherence to infantile rules, you start searching around for better rules, right? Hang on – now we’re back to the same problem, and we add a new one – change fatigue. Doing things in one way creates baggage. It affects the way you think and it creates artifacts built using those methods. It represents an investment. All of this means it is hard to change on so many levels that you may find yourself experiencing change fatigue – that feeling of unfamiliarity which drains your will to do things and makes you less productive. This is what I am experiencing now.
    I should have a poster made, I think, with “Le mieux est l’ennemi du bien” (the best is the enemy of the good) printed on it. Or perhaps I should find a way to let go of dogma altogether and just get things done. After all, aphorisms may be pleasing but Voltaire also said “Un bon mot ne prouve rien” (a witty saying proves nothing).

  • Productivity: perception vs reality

    I am haunted by the thought that somewhere someone is doing what I am doing more efficiently. I pride myself on knowing efficient ways to do things. Note that this is somewhat different from “being efficient”, which in many cases involves not learning new ways of doing things you will probably just do once. I have slowly learned that I am fooling myself when I figure out ways in which to do things better next time, as there probably won’t be a next time and my time is largely wasted.

    That said, the feelings aren’t going away, and in fact I have learned things that make it even more difficult to figure out what’s going on. Witness this discussion – the meat of which is that keyboard shortcuts feel faster but mousing is actually faster as measured by a stopwatch. Oh no! Now I need to time myself doing common tasks instead of relying how productive I feel? This brings up an even more interesting question: What is more important to me day to day, being productive or feeling productive?
    The sad truth is that I have come to the conclusion that much of my investment into learning lots of different ways of doing things and even the environments that I enjoy the most have been focussed on making me feel productive rather than improving my actual productivity. Unfortunately I am now experiencing the sunk cost dilemma. I have spent almost 9 years of my life learning (and I stress that I have aimed to become proficient rather than just getting by) Linux, grep, sed, awk and all the unix tools and gnu plotutils so that I can do tons of stuff from the terminal. I have learned Emacs, memorising its arcane and non-transferrable shortcut keys and how to interface it with the shell commands. In Emacs I have learned AUCTeX for latex editing, where I often write code for pictures. I also use org-mode a lot for task management. I suppose my investment into learning Python was the least contentious of these decisions. On the way I have also shed Matlab and ignored powerful but expensive tools like Mathematica in favour of SciPy and Maxima, and lately Sage. I have replaced Simulink with Modelica.
    I am now beset by doubts and I wonder if I shouldn’t have taken the blue pill after all and when I started getting into Open Source when I graduated, just continued with my Windows box, installed Visual Studio and rekindled my original love for C++, used MS Word for my Masters and Matlab or even Excel for all my data processing, or perhaps laid my hands on Mathematica or MathCad. Would I not be more capable now and would I have not gotten more things done in the end by not going against the flow?
    Unfortunately there is no easy answer. I am typing this on a MacBook Pro, which I love because Mac OS X has a nice unix layer beneath it but also because there are less hardware issues than I have endured using Linux. I have not yet been successful in using XCode to do anything meaningful because I don’t want to write an app that I can’t use on my Linux box at work. I have found myself developing code that I am forced to maintain and run simply because I am the only guy on my floor that has Linux on his machine and I have not wrapped the stuff in a GUI so that our secretary can run it. So I experience the need post facto of being able to create GUI apps and have other people run them, and of having a common environment that people can help me with.
    However, every time I look into the “more productive” way I feel like gouging my eyes out. I hate word processors of pretty much every description, as the whole philosophy of “when it looks right it is right” galls me, and figures don’t float – what’s up with that? When I try to use Eclipse for development, I am up against the problems of using such environments for dynamic languages, in addition to the fact that all my current projects’ directory structures don’t lend themselves to Pydev’s idea of what a Python project should look like. In fact, when I try to use statically typed languages, I feel totally put out by having to think of the type information in the first place. I cannot find an easy way to get from where I am now into the mainstream, and it annoys me.
    I have vowed to stop looking around for now, until I have finished my PhD, but once that is done, should I become a good little MS drone? Have I wasted my time learning these skills or can I justify my rationalisation that I am more productive now? Does that even matter when I feel more productive (and happier) when I am using my current environment?