Negative Feedback

Year: 2012

  • The impact of environment: how much do IDEs contribute?

    Those who know me will know this is a much-beloved topic of mine. I am setting this stuff down in an attempt to purge some of these thoughts from my brain.

    During a conversation with a colleague yesterday, the idea of language productivity came up. It’s an old argument: sure, you can write less lines of code in say Python than in Java (see my post on this topic), but with a modern IDE, you’ll end up ahead as the IDE will be doing a lot of that typing for you. This forms part of a bigger conversation about the relative power of different languages, the relative merits of various IDEs and the way the brain works, before and after exposure to various models of computation. So, I’ve been maintaining a variety of links to research on these topics, and I’ll try to state my current understanding succinctly in the next couple of paragraphs. I would really value any feedback that you could give me (for the handful of people who actually read this). Although I enjoy reading anecdotes of personal experiences, I would appreciate most if you could point to proper scientific studies on the topic.


    So, this study, from 2000, compared C, C++, Java, Perl, Python, Rexx, and Tcl for a particular programming task: in this case a program to find which words could be spelled with particular phone numbers using the normal keypad letter mappings. They found that the “scripting language” programs were significantly shorter and took less time to write, but did not perform significantly poorer than the compiled languages. An interesting feature is that the compiled languages (C, C++ and Java) required considerably longer programs and took longer to write. The lines/hour for all languages were roughly comparable. They don’t mention which IDEs the programmers were using, but one assumes that at least some of them were using “modern” IDEs. A 2003 interview with Guido van Rossum, highlights this idea of Python requiring less “finger typing”. He’s obviously biased as the creator of Python, but considering that he also wrote the Python interpreter (in C) and has a large realm of experience in various languages, one would think he has had some time to experience the differences.
    Another study, from 2009 may explain a part of this. They found that reading code was largely a function of the number of tokens. This is important, because it implies that less tokens can aid in understanding already written code and have an effect on writing it. Importantly, they also find that simple domain mappings are easier to comprehend than complicated ones.
    I have not been able to find much quantitative research on the benefits of IDEs. Although I acknowledge that environment makes a big difference, I tend to think about code in my head without an IDE, which makes the actual language quite important for me. To some extent one must acknowledge that there is a personal aspect as well – some people prefer a particular kind of approach, as shown in this article about language mavens vs tool mavens, which I’ve linked to before. I’ve slowly been learning Eclipse, and it is quite amazing how much of the mundane Java stuff it can automate. I’m also a great believer in refactoring tools (I use rope, with bindings for Emacs). At the same time it is clear to me that much of the stuff you get in Eclipse could be addressed by streamlining the language a bit.
    Finally, the larger picture about fitting into an environment. This is where the established languages have the upper hand. Popular languages are more widely known, have more books and environments available and have the corporate OK. Also, if the libraries of the operating system you are using have been crafted for a particular language, there is a clear advantage to aligning yourself with that. As a researcher, though, it is often a bit of a conundrum: the real publishable results are more important than the interface, so you find the majority of computational research code has no GUI, and is only lightly coupled to the host OS. This is especially true of parallel code which inevitably has to run on headless cluster boxes.
    I don’t want to make this another post about choosing a programming language, but I will restate my final strategy: use the most expressive language available for prototyping – this will inevitably be a dynamically typed language with a REPL. For me, this is Python. This hooks into the constant lines per hour result of before. When the program produces the correct output and the algorithm is set, re-implement the slow bits in a lower level language. For me this is Fortran, but it could be C++ or whatever has good support for your problem domain. This strategy has placed me a in a poor position to benefit from IDE support. For that, you typically want to do everything in a combination of IDE and well-supported language (this is the classic Java/C++/C# for everything approach).
    Anyone with links to proper quantifiable research on programmer productivity (especially the effect of IDEs)?

  • Unchecking heard podcasts in iTunes via AppleScript

    Because I have a small 16 GB iPhone which is way less than the size of my music library, I use the “sync only checked items” approach. However, I want podcasts I have listened to already be unchecked as well. For that reason I’ve written this little Applescript which runs through all the podcasts and unchecks the ones I’ve listened to.

    tell application "iTunes"
     set thetracks to every track of library playlist 1 whose podcast is true and enabled is true and unplayed is false and bookmark is 0
     repeat with currentTrack in thetracks
      set enabled of currentTrack to false
     end repeat
    end tell

    This was slightly harder than it looks due to the fact that iTunes uses the “unplayed” property to indicate it has never been played, ever. When you’re halfway through, though, a tracks’ “unplayed” is false, but you don’t want to uncheck it. In the iTunes GUI a blue dot indicates played, a half-filled blue dot played but not finished and no blue dot is played and finished. The breakthrough is in the “bookmark” field, which gets set to the position in the file you last listened to. Kindly, Apple sets this to 0 when a track is completely listened all the way, leading to the conditions above.

    You can use the AppleScript editor to create this file and save it as “Uncheck heard podcasts.scpt”, then save it in your Library/iTunes/Scripts folder. When you restart iTunes, it will show up in the script menu.

    This is a good example of how knowing a scripting language can help you out.