Thinking outside the box: What would an idiomatic ruby IDE look like?

[Ed Howland]

Just ruminating here.

Traditional IDEs, even the screenshots of Ruby based ones I've seen,
seem to follow the Visual C++ Studio model. (Not sure of they
originated it). There is usually several window panes surrounding an
editor/debugger pane. These have various inspectors or explorers in
them (stack viewer, project tree etc.).

All of these IDEs seem to tackle the approach from the outside-in.
Editing files, executing/debugging whole programs, parsing the entire
object/class hierarchy etc. This sort of style seems necessary for
low-level debugging of object oriented programming languages like C++,
Java etc.

How would an idiomatic Ruby approach look?

It seems to me that there are at least 3 aspects of the Ruby language
that are fundamental to understanding the syntax and the semantics.

1) All elements are objects and respond to messages.
2) Blocks/Procs take on a huge precedence in coding style.
3) Enumerations are all the rage. Collections are used everywhere and
have a similar footprint.

For #1, what if the editor/debugger could be sent messages within the
"scratchpad/irb" window. For instance, if you could set a breakpoint
inside a loop, and then send a message to continue to that breakpoint.
This would then be highly scriptable. You could arrange to iterate the
loop only X times, and then stop. I think this is a powerful idea, and
not limited to debugging only Ruby programs.

Another expansion of this idea is to be able to create a custom widget
for debugging.

What if you could use a block in the debugger context? In the
scratchpad, what if I was to write the following code:

Debugger debug do
a=MyClass.new
a.my_method
end

By default, it might step into the block awaiting the next debugger
command. Or it could be modified like this:

Debugger debug(:run_until_exception=>true) do
a=MyClass.new
a.my_method
end

Which would run till it hit an exception, setting the editor focus to
that file window/line #.

For #3, the editor could be considered a collection of lines or statements.

Editor.lines.map {|l| l.colorize!}

Or the editor could expose the internal AST (Ruby 1.9 has the Ripper
stuff). This could be walked in the scratchpad, or a custom inspector
could be created.

Any other similar ideas?

Ed

Cheers,
Ed

Ed Howland
http://greenprogrammer.wordpress.com
http://twitter.com/ed_howland

[Iain E. Davis]

On Aug 30, 10:05 am, Ed Howland <ed.howl...@gmail.com> wrote:
> For #1, what if the editor/debugger could be sent messages within the
> "scratchpad/irb" window. For instance, if you could set a breakpoint
> inside a loop, and then send a message to continue to that breakpoint.
> This would then be highly scriptable. You could arrange to iterate the
> loop only X times, and then stop. I think this is a powerful idea, and
> not limited to debugging only Ruby programs.

It'd make "conditional breakpoints" have the potential to be much more
sophisticated. If the Debugger is an Object I can talk to, or extend/
modify the Ruby way, then I could add special handling to my
breakpoint; perhaps I only want it to "halt" after X iterations, AND
only if variable foo is non-nil, AND ... so on.

Visual Studio provides a mechanism for looping X times and 'break':
You can set a breakpoint so that it has to be "hit" X times before the
program execution halts. Its come in handy when I've needed to trouble-
shoot a problem that only occurred late in a loop with many
iterations. :)

> Another expansion of this idea is to be able to create a custom widget
> for debugging.
> What if you could use a block in the debugger context? In the
> scratchpad, what if I was to write the following code:

[code snipped]

>
> By default, it might step into the block awaiting the next debugger
> command. Or it could be modified like this:
>

[code snipped]

> Which would run till it hit an exception, setting the editor focus to
> that file window/line #.

I really like this idea. My impression of it is that it gives a very
direct way to test/debug a specific method or class. More so than you
might see in another IDE (or language).

> For #3, the editor could be considered a collection of lines or statements.

Hmm. I'm not able to see in what way this would be helpful to me (as a
developer). Customization of the IDE itself?

---

I do have a worry that features like these will intimidate users brand-
new to the IDE, so in _addition_ to them, it'd be important to provide
a mechanism for breakpoints and debugging that operates in a
"familiar" way. Even if that mechanism is simply doing the code above
_for_ the user...in fact, that'd be particularly good if that was
visible, then the user could, as they get used to the IDE, learn how
to do familiar things in the syntax, and then expand upon it, either
through their own experimentation or via discussions with other
users. :)