BDD is short for Behavior-driven development. The Wikipedia article on BDD is really long, but as far as I can tell BDD is better summed up as: “When you’re writing code, examples are really helpful so you should get as many as you can stomach. If anything is unclear, ask for some more examples.”

I don’t know if it’s strictly in following with BDD, but a lot of the time I ask for examples that aren’t like previous examples. That can be pretty enlightening.

While mucking around with Perl’s Test::Simple I needed to find out the name of a sub routine from a reference. While there are several answers, finding any useful ones by the usual means was difficult. The one I landed on was using Sub::Identify, which provides the routine sub_name($) that solves the problem nicely.

Tor Norbye’s series of weekly screenshots of cutting edge NetBeans features is interesting, but the feature displayed in this recent one has made me wonder about the balance between what IDEs can do and what they should do. The feature is fairly simple, adding a type annotation to function/method parameters in python so NetBeans can recognize the expected type and grant semantic auto-complete for the parameters. In my opinion, this steps over the line of what an IDE should do. Here’s why I think so.

What an IDE should do (when editing)

When I’m typing, I want the editing environment to enrich my ability to type. If I’m typing plain text, some sort of word-completion is a benefit. If I’m typing code, word-completion is useful, but semantic code completion can be much more useful. I say can, because sometimes the limitations of the IDE impede the usefulness of code completion. When the IDE doesn’t know how to do the right thing, I often find myself yanked out the context of the code and either have to rearrange myself to what the IDE has done (in dynamic languages, often expanding every possible completion regardless of type) or consult an external source on what options are available. Both these actions are undesirable, because they take me out of my primary focus (the code). The code completion I’ve been doing up until this point has also conditioned me. I am conditioned by the IDE to use code completion as part of my writing process. When code completion fails, I have a failure in my writing process. It follows of this that it is desirable that code completion never fails.

When I am writing code, I’m generally writing just one language (or in some cases, such as php, erb templates, django templates, jsp, a markup combined with one language). Therefore, I want my editing environment to support the writing of that language. When I am writing Java, this means aggressive code completion, templating and creation. In fact, templating and code creation is actually more important to me in Java than code completion. Java requires a lot of boilerplate and ceremony, and the more of this the IDE can take off my hands the better. When I’m writing Python, I want the IDE to flag stuff like undeclared variables, missing imports, code style and many of the other things Nordbye has demonstrated over the last weeks. I do not, however, want code completion. Maybe this is because I don’t write much code that interfaces with Python libraries, but I prefer word completion. But the primary reason I don’t want code completion is that it will fail. I don’t want to introduce failures to my writing process.

What an IDE should not do

Simply stated, an IDE should support the language in question. It should not expand the language. The commented type annotations in NetBeans change Python. Changing the language means that the code acquires noise when viewed in other editors. Other editors do not parse anything of value from the commented type annotations.

I also think that adding semantic value to comments is a bad idea. Since comments don’t fail when code is updated, there is a very real possibility that a method’s parameters can be updated without the type annotations being updated with them, possibly causing NetBeans to code complete for the wrong type. This is a failure, and the result is even worse than the failure above, since the IDE is now helping you write patently incorrect code.

What I’m suggesting

It’s bad form to criticize without suggesting an alternative, so here goes. I don’t know if this is feasible, and it’s almost certainly more work than the type annotations were.

I would like my IDE to support my normal habits when I’m writing Python. What I was taught in my early Python days, was that the REPL is your friend. This is not just because you can test code snippets in it, but because Python is self-documenting. Documenting comments are generally not written with comments, but with docstrings. A great way to get help about something is to run some introspection on it, or use the dir() or help() functions. The dir() function lists all methods available on an object. The help() function provides a formatted and paged listing of a type and its methods.

What I would like is for my IDE to assist me in using these functions. For example, if I’m looking for some documentation on the str class (as Nordbye was doing in his example), I’d like to be able to view the results of help() on some type in a panel in the IDE somewhere. The exact way to input that type’s name should be up to better interaction designers than myself, but some sort of dialog that accepts the typename bringing up a panel displaying the help page would be most useful.

The code completion mechanism could then rely on this documentation panel as a ‘hint’ when type inferencing fails. That said, it should probably be clear from the drop-down that completion is being done from the documentation, so it’s clear to the developer why string completion is being done when I’m dealing with something I know not to be a string.

When I tried out the NetBeans nightly build for Python to get an idea of how intrusive the comments were (too much so) and how well the other stuff worked (very well), the only time I needed explicit type annotating failed. I was dealing with a dict filled with lists, and wanted a method for the list that I didn’t know what was called off-hand. I was not altogether pleased by this, but the overall feel of doing Python development in NetBeans was quite good. Editing felt snappy and responsive. It was very easy to import my existing project (with a non-standard layout) to NetBeans and both navigating through the project and editing worked very nicely.

I’ve spent some time looking at Emacs Lisp lately and there’s a weird ecosystem going on there. ELisp (and I’m thinking primarily about Emacs configuration here) tends to grow organically, because it’s paced by a person’s learning of the editor. Every now and then someone needs a new function, and they either search or ask around for something similar. Either it’s been implemented before and the code can be copied into their local Emacs configuration or they can write a simple version that is sufficient for initial usage.

In particular, I noted two things. In djcb’s dotemacs, he defines macros for conditional requires, that degenerate gracefully when required libraries are unavailable, instead of erroring. It similarly has a macro when-available, that runs some code if and only if a given function is available. These are used liberally throughout his configuration, making it robust against unexpected environmental differences. When I first saw this I considered it clever (and still do, really) and wondered whether I should include something similar in my Emacs configuration. In the end I decided against it, because I only use Emacs in very similar versions on two machines and version control libraries that are missing from either or both systems. This ensures that I rarely see errors from missing requires or functions.

In emacs-starter-kit the use of ELPA, the Emacs Lisp Package Archive, intrigued me. I’m a big fan of package management, though I tend to be of the ‘one package manager to rule them all (per system)’ crowd. Using ELPA instead of (re-)versioning all the external code I use seems like a good idea, though I’ve put it off for a bit due to the number of comments to the effect of ‘workaround for bug in ELPA’ in the starter kit. I’d also like a web interface to browse available packages and accompanying source so I can check on the status of all the libraries I already use.

Thinking about both these things, gracefully accepting the limitations of environment and package management for dependency resolution, I started to wonder about other best practices for ELisp. While Emacs is a huge framework in and of itself, the incremental improvement pattern for building ELisp doesn’t exactly invite to build other frameworks. So I wasn’t very surprised when I found that the only unit testing framework is quite new and not generally accepted as the right way to test ELisp (discussion here).

None of the advice or ideas I’ve found have really addressed the practice of writing ELisp, maybe with the exception of Steve Yegge’s save-excursion post. Even people who talk about modularity don’t generally mention how to best organize ELisp modularly. This isn’t necessarily bad. The lack of clear practices does mean one has to make a lot of judgement calls on what the right thing to do at any given point is, taking into account the one’s own requirements and limitations.

I have a box with Ubuntu 7.10 (Feisty Fawn), which EOLed back in October. Now that I have a few days to spare over the holidays I thought I’d get around to upgrading it to something current. Unfortunately when Feisty was EOLed they moved the package repositories. The new mirror is at old-releseases.ubuntu.com.

The error I was getting looked like this:# do-release-upgrade
....
E: Some index files failed to download, they have been ignored, or old ones used instead.

Apt should correctly update all packages to your EOLed release’s final version. When that was done, I was ready to upgrade to Gutsy. The upgrade manager the Ubuntu folks have come up with is pretty slick, but doesn’t take into account that you might be running an apt mirror that doesn’t also serve the version of the distro you’re upgrading to. Oops. Getting it sorted isn’t that big a deal. I started it.

Then, when prompted for information about my mirrors, I backgrounded do-release-upgrade with C-z and fixed my source.list again, this time to reflect a repository that was invalid for Feisty, but valid for Gutsy:
# do-release-upgrade
...
Updating repository information

No valid mirror found
While scanning your repository information no mirror entry for the upgrade was found.This can happen if you run a internal mirror or if the mirror information is out of date.

Do you want to rewrite your 'sources.list' file anyway? If you choose 'Yes' here it will update all 'feisty' to 'gutsy' entries.
If you select 'no' the update will cancel.
Continue [yN]
[1]+ Stopped do-release-upgrade
# sed -if 's#old-releases.ubuntu.com#us.archive.ubuntu.com#' /etc/apt/sources.list
# fg
y

So it seems the Rails community is looking at alternative editors. This post by Daniel Fischer gives a pretty good overview. I have to say I approve. Not that TextMate isn’t good. It is. But it’s very cool for Emacs (and Vi!) that a community that focusses a lot on sharing knowledge and techniques is taking up these editors.

For me this video on ido-mode was a big win. I’m also a fan of the Emacs in 5 minutes demo, and there are many more here. There are also a couple blog posts going around on experiences with both vi and Emacs, usually comparing them to TextMate. What these three have in common is composability and scriptability. I constantly butt my head against the lack of it in fullblown IDEs. Eclipse, which I spend a bit of time in from day to day, doesn’t even have any decent support or plugins for keyboard macros. It’s so easy to forget when dealing with editors that recognize ASTs that programming is fundamentally about editing. Sure, the stuff that we can do with refactoring tools is impressive, but if it’s taking focus away from thinking about how you can do your own refactorings, it’s probably hurting as much as it’s helping.

Here’s some emacs stuff I use regularly. My dotemacs stuff is available at github if anyone’s interested.

ido-mode – A minor mode that makes many functions autocompleting. My favorite little touch is how it looks at recently opened files when trying to autocomplete filenames. I use this to look up configuration files deep in Java projects quite a bit.

tramp-mode – Open files over almost any remote (or local) protocol. The linked page has find-alternative-file-with-sudo that opens local files with sudo, which is nice.

yasnippet – Obligatory snippet minor-mode. I’m not a huge fan of the default binding to tab, so I’ll need to find a better one eventually.

nxml-mode – A superior editing mode for XML and XHTML. I don’t even use this properly (yet), and it’s still superior to Eclipse’s default XML editor.

Various language modes – There’s a fantastic major-mode for Erlang. There’s a great one for Scala (superior to anything I’ve seen in an IDE with one caveat: I can’t get maven projects to compile correctly, yet). I haven’t tried out js2-mode yet, but I’ve heard good things. In general people create these for Emacs sooner and better than many IDEs (though some of the NetBeans 7 stuff looks impressive.)

I use Emacs on Ubuntu 8.10, where I use emacs-snapshot-gtk, which is a stable snapshot from CVS. On Mac OS X I use Carbon Emacs, though I’m probably going to move to a build of Emacs.app next time I upgrade. Carbon Emacs is pretty good, but has a couple of weirdisms that I don’t like. For example, the zoom button doesn’t fill the screen, it just makes the frame 80 columns wide (fixed by max-frame).

While I’ve taken a couple potshots at IDEs in this post, I’d like to emphasize that while there is a difference in philosophy, and I adhere to the “editor first, code manager second” philosophy, but the IDEs are getting there. The editors didn’t just start out awesome at editing, and the IDEs didn’t just start out awesome at code managing. Both of them are constantly improving and the choice for the future isn’t necessarily clear. All in all, I’d say it’s a good time for both of them. More people are diversifying, both between editors and IDEs. This is a good thing too, as it’ll drive improvement further.