NetBeans 6.0: Interview with Tor Norbye

I just saw the news the NetBeans 6.0 is out, featuring some great Ruby and Rails support. Tor Norbye and the rest of the NetBeans crew deserve some major kudos for all their work.

Tor was nice enough to take a couple of minutes to answer some questions about Ruby and NetBeans for me. So, here goes—

---

Why should Ruby/Rails folks who are busily hacking away in emacs/vi/textmate/whatever take the time to download and try out NetBeans?

Tor Well, there are a couple of features that they might find boost their productivity. You may not want to switch to NetBeans, but you can add it to your toolbox and pull it out when you need it.

(1) The first such feature is integrated debugging. After some pretty minimal setup (installing the fast ruby debugger gem) you can easily debug your Ruby and Rails applications, single stepping into and over statements, setting breakpoints, looking at the call stack, looking at local variables, drilling into data structures – even just hovering over variables in the editor to see their current values as tooltips. This doesn’t only work in Ruby files – it works equally well in ERB/RHTML files.

(2) The second feature I’d like to highlight is semantic editing, where by utilizing a parse tree, NetBeans can add some extra functionality. The most obvious is Quick Fixes. Briefly, quickfixes are little semantic checkers that look at the parse tree and look for potential problems. When these are found, it puts a little lightbulb in the margin to alert you to the problem, and the user can then look at the problem and decide what to do about it (most of these semantic checks also offer options to fix the problem automatically).

Thus, these quickfixes are like “lint for Ruby”, and even if you prefer to stay in your current editor, you might want to open your sources in NetBeans occasionally and let it check your code. Examples of bugs it looks for are:

• Accidentally assigning to a local variable instead of the intended attribute of this class (a pitfall listed early on in the Pickaxe book—as I was learning Ruby I immediately dogeared this page because I decided I wanted NetBeans to detect this problem and I recently got to un-dogear it :).
• Accidentally reusing a local variable as a block variable
• Accidentally assigning to a variable in an if-block
• Calling a deprecated Rails API (e.g. using @session instead of session, or link_to_image instead of link_to, etc.)

(Many of these hints are not in the base 6.0 download, but they are on the 6.0 Stable Plugin Center which you can access from within the tool. For a full list of the current hints, see the RubyHints wiki page)

(3) There’s some other editing functionality available that you might find useful:

• Extract Method and Introduce Variable: This lets you very easily break down long complicated methods into smaller units; again, by using the parse tree NetBeans can ensure that the code fragment is correctly pulled out by passing in all required inputs and passing back out all required outputs.
• Rename Refactoring: While not as accurate as in Java, this is still better than relying on search/replace, since NetBeans for example will not mistake a reference to the local variable “foo” as a reference to the unrelated method “foo”
• Go To Declaration, which lets you quickly jump around in classes. Useful for exploring new classes.

(4) ERB/RHTML editing. While many editors support Ruby well, the ERB files aren’t equally well supported. Quickfixes, refactoring and reformatting for example, all work in RHTML, so if you’re editing ERB files a lot and want to reformat them etc. you might want to try NetBeans for that.

I realize I’ve gone on way too long, but it’s very hard to stop myself :)

What was the hardest thing to get right?

Tor Type inference, by far. It’s impossible to do it accurately. Luckily, Rails in particular follows a lot of patterns, so NetBeans can use heuristics that work out well in most cases. I tuned these up to the very end of the release, and in the process I’ve learned a lot. But the more I get done, the longer the TODO list grows with new ideas…

What still needs the most work?

Tor Well, I think Type Inference is certainly the area where there is the most potential work available—I could probably spend ten years improving it. However, I feel okay with the current level of inference; I think Ruby users “get” the amount of inference we’re doing and when they can and can’t rely on it. I have some targeted things I’d like to achieve in the next release but I don’t think they’ll be dramatic.

I think our weakest area right now is the terminal handling (for running IRB and Rails consoles etc). Many Rails tools like to emit terminal escape codes to colorize the output; RSpec for example will use colors to highlight its summaries, ActiveRecord colorizes SQL logging output, etc. Our output window doesn’t support terminal escapes, so we simply strip the codes out for now, and furthermore, we’ll need full proper terminal emulation as well as pseudo terminal support to properly handle “readline” interaction which is required for running IRB. Similarly, tying IRB sessions (or even running scripts like the Rails generator) into the IDE with consistent color highlighting, completion etc. would be highly desirable.

If you could wave a magic wand and add one Ruby/Rails related feature to NetBeans, what would it be?

Tor It would probably be the above output window improvements. I’ve looked at terminal emulator code before, and I’m not looking forward to it…

What non-IDE tools do you think Rubyists should be using more?

Tor Well, one area I find a bit lacking in Ruby is the documentation area. While most classes are well documented at the top of the file, individual methods and attributes are often, let’s say “sparingly”, documented. This might be because users are intended to look at the source code for any libraries they are using and would naturally read the top of the file to learn about the library. This doesn’t work so well for people exploring the API via something like code completion (or even “ri”). It would also be nice if the libraries would be clearer about what is “exported API” and what are “implementation” methods not intended for public consumption. One of the things I added late in the 6.0 cycle is making code completion filter out any methods marked ”# :nodoc:”, and that helped a bit, but I’ve seen a lot of code that I believe are implementation artifacts and shouldn’t really be exposed from the class, so would be prime candidates for #:nodoc. So, in short, I’d love to see the documentation improved a bit. This is not exactly a tool per se, or perhaps I’m really advocating the use of “rdoc” more to view the docs for the code you’re writing. (I’m sorry for bringing things back to an IDE at this point—I can’t help it since I’ve worked on IDEs since 1996. One feature I added to help with this in NetBeans is that while you’re writing a comment, you can just type Ctrl-Space, and the IDE will pop up an HTML view of the comment you’re writing (processing all the RDoc conventions).

Anyway, it’s been really fun to join the Ruby community; there are a lot of enthusiastic and talented programmers here!