I don't see why Ruby is any different from, say, Javascript in this regard. "IntelliSense" for Javascript has always been mediocre in all the IDEs I tried. So I don't think this is a new problem, although I'd much like to see a solution!

This looks great. Have you seen the Dolphin Environment for SmallTalk? I can imagine this making coding in Ruby similarly easy.

You might even make me stray briefly from my love affair with JetBrains IDEs to dabble in Ruby for a while.

Congratulations.

Some of the features such as anonymous methods and lambda functions, method extensions etc in future c# versions should help.

After all, Linq is #almost# a dynamic language.

Same goes for other dynamically typed languages like PHP or Perl, Ruby is not unique in this regard. IDEs, even the might Eclipse, tend to struggle with IntelliSense for such languages, at least now I have some understanding why ;-) Thank you for the entertaining post!

It's strange to hear that this is a surprise to anyone, especially someone who's knowledgeable enough to write an IDE. It's for exactly these reasons that Java and Coctothorpe were designed to be type safe. Inheritance and variable types are determined at compile time, not run time. If you're writing auto-complete for Ruby, you'd really have to run every iteration of every combination of methods in the program to figure out what the the type of a variable might be at any given time. For example, how would you determine the type of the variable in this code (sorry about the indentation and extra spaces)?

class TestClass

def initialize(testValue)

@testValue = testValue

end

end

You'd have to find every method that might ever call it, which may not even be possible if this is a library. It's much easier to design and write an IDE around type safe languages. It's also much easier to have the compiler check the correctness of your code than to have to run hundreds of extra test cases to make sure that your string is always treated as a string or that, when a user enters a value, you remember to convert it to its proper type (date?) and don't accidentally leave it in string form.

Not a big fan of dynamic languages then, Huw?

Despite your (half-joking?) assertion Ruby is not "random" or "unpredictable" any more than any other language. Dynamic languages present fewer constraints, but also confer greater responsibility; you generally need to know what you're doing.

Intellisense may be absolutely essential in a framework with a billion methods but, if used properly, dynamic languages allow a level of abstraction and conciseness of form and syntax that reduces the volume of information you need to commit to memory.

I've used C# fairly extensively, and I just don't buy the "benefits" in comparison to dynamic languages. It *needs* a huge supporting structure and crutches like intellisense because it's complex and monolithic.

And don't get me started on they way's that increasing reliance on Intellisense, and all it implies, constrains the design process...

I'm convinced you're really a fan of dynamic languages. Surely the best solution is for your intellisense plugin to run Ruby in the background, and use its introspective powers to provide the auto-complete options?

http://blog.wordaligned.org/articles/2007/02/02/code-completion-for-dynamic-languages

Fan of dynamic languages...?

Well, up to a point. Let's just say that having spent the last year of my life working on an IDE for Ruby, I guess I must have a certain fondness for the language.

As for the benefits of IntelliSense. There are those people who never use it and those who can't live without it. I suppose I am in the latter group. To me, IntelliSense is more than just a quick way of entering code - it's also a documentation and code-analysis tool. An IntelliSense list should provide you with information about the scope, context and ancestry of an object. It should give you information derived from 'required' (i.e. "imported" or "used" files) and 'included' (or "mixed in") modules.

In my view, you can never have too much information when you are programming an application of any complexity. You can, of course, disable some or all of the IntelliSense if you really dn't want it. But personally, when I don't have IntelliSense ready to hand, I find I waste far more time hunting through the Ruby documentation for information that would otherwise be a dot or a hovering tooltip away...

The really hardcore stuff happens when you add meta-programming and other code-altering mechanisms into the mix. Creating methods on the fly that depend on user input would be potentially impossible to intellisense correctly...

And even very hairy value-flow analysis can't solve the intellisense problem when comfronted with "Lame Duck Typing" (see http://def-end.blogspot.com/2006/11/lame-duck-typing.html) What may be a possible completion in one place is not always possible in another, not only because of scope, but because of timing!

I love intellisense, and can't begin to tally the hours it's saved me when writing Java in Eclipse or C++ in VS. But Ruby and other dynamic languages require a tool to have more than just mechanical smarts to do the really dynamic stuff. When you factor in runtime variability, you're *always* going to come up short.

There are, indeed, some cases where it is, even in principle, impossible to infer type information in Ruby. e.g.

def aMethod( a, b, c )

doSomethingTo(a, b, c )

end

When no class types can be inferred, we default to Object. The parameter info tooltip for the above method would be...

aMethod(a:Object, b:Object, c:Object) : Object

But while this is true, it is not very helpful. For those people who want more type information than Ruby can supply, we have added optional 'type assertions' which can be placed in a comment over any method in which the types are ambiguous, like this:

#:return: => Array

#:arg: a => String

#:arg: b => MyObject

#:arg: c => Array

def aMethod( a, b, c )

doSomethingTo(a, b, c )

end

Now, the IntelliSense parameter tooltip will say:

aMethod(a:String, b:MyObject, c:Array) : Array

The advantage of placing assertions in comment blocks is that they do not alter the meaning of the Ruby code outside of our the Ruby In Steel IDE. However, when you work in the IDE, assertions act as both code documentation and as a source of 'expected type' information to be used by IntelliSense.

...is a favourite hobby of mine.

But I'd guessed you must have at least a love-hate relationship given the reasons for your original supposition :-)

I can understand people liking IntelliSense, I just think it pushes you onto a slippery slope of consquences that ends up having a disproportionate and damaging influence on the software development lifecycle (at least in

some "classes" of software system/application).