back to article Making sense of Ruby

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 …

COMMENTS

This topic is closed for new posts.
  1. Mahmoud Al Gammal

    What about Javascript?

    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!

  2. Anonymous Coward
    Anonymous Coward

    Congratualations

    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.

  3. Anonymous Coward
    Anonymous Coward

    .Net CLR v.Next might help

    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.

  4. John Collins

    Ditto for other dynamic languages

    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!

  5. Connor Garvey

    Really??

    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.

  6. Sean Inglis

    Loaded Language

    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...

  7. Thomas Guest

    Interesting article

    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

  8. Anonymous Coward
    Anonymous Coward

    It's even worse than that...

    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.

  9. Sean Inglis

    Leaning against open doors...

    ...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).

This topic is closed for new posts.