Making sense of Ruby

An IntelliSense Cure for Method Madness?

Hands on We were six months into the project before we even realised we had a problem. Until that point, we had assumed IntelliSense was a trivial matter that could doubtless be wrapped up in an afternoon’s coding. After all, how hard can it be to program some lists of names that drop down when someone types a dot?

The answer, as we were soon to discover was: very, very hard…

The project in question is called Ruby In Steel and it’s a Visual Studio development environment for the Ruby language. Ruby is a so-called "dynamic" language, which is a polite way of saying that it's hugely unpredictable.

A Ruby program is so dynamic that you can never be sure what it is up to from one moment to the next. To take a simple example, when you write some stand-alone functions into the editor, those functions get bound into the base class of the entire Ruby class hierarchy. That means that every single Ruby class automatically "inherits" them - and the IntelliSense system is expected to know about it!

If we'd been developing an IDE for a more traditional language – C# or Java, say – life would have been so much easier. Those languages go to great lengths to tell you what they are up to. Each variable declares its data-type in advance and when a variable starts life as an integer it’s pretty safe to assume that it’s going to stay an integer until the great garbage collector in the sky finally pops it out of existence.

With Ruby, you can't make any such assumptions. The types of variables are not declared and they are infinitely changeable. A variable called x might be start out as "Hello world", suddenly change into 76.23 and, just for the heck of it, end its days as a small fluffy Teddy bear object called Eric.

Some code-completion systems solve this problem in a cunning way - they cheat. Instead of working out what type of object x is at any given moment, taking into account all the difficult stuff such as its scope, inheritance and context, they work alphabetically. If someone enters a dot followed by the letters ‘my’, they drop down a list of names such as ‘my_method’, ‘my_othermethod’ and ‘my_random_guess’ whether or not those methods have anything to do with the object in question.

Illustrates Ruby in Steel Intellisense.

Creating real IntelliSense (as in Figure 1) is much harder. The only way to do it properly is to analyse the code much as the Ruby interpreter itself does. The big difference is that the interpreter only goes into operation when a program is complete whereas an IntelliSense system has to deal with code that is constantly changing due to editing. After each change, it has to reanalyse the code all the way back up to the root of the entire class hierarchy. This sheer complexity of this analysis explains why IntelliSense systems for dynamic languages are not that thick on the ground.

Programmers often say that one of the defining characteristics of Ruby is that it's so much fun. All I can say is, they obviously haven’t tried programming IntelliSense for it! ®

Sponsored: Driving business with continuous operational intelligence