[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Open letter to anyone developing a Ruby IDE

Adelle Hartley

3/30/2005 12:38:00 AM

It has been said that features like "intellisense" or "autocomplete" are
difficult to implement for dynamic languages such as Ruby.

I'd be happy with an IDE that let me choose a .rb file per project, let's
call it "environment.rb" which would usually be a list of "require"
statements which would establish a run-time state that would be a fair
approximation of what classes and methods would be available to 90% of my
application.

I mean, sure, dynamic languages let us add/remove classes variable and
methods anytime we like, but during the first moments of my application's
startup I usually set up 90% of the classes that I will need during the
remainder of the program's execution.

Adelle.
24 Answers

Lothar Scholz

3/30/2005 1:35:00 AM

0

Hello Adelle,


AH> I mean, sure, dynamic languages let us add/remove classes variable and
AH> methods anytime we like, but during the first moments of my application's
AH> startup I usually set up 90% of the classes that I will need during the
AH> remainder of the program's execution.

The difficult thing is not really gathering of information. It is the
way how do you want to present the thousands of methods
found in your files and the runtime library.

Since type interference is quite impossible the only solution i came
up is some kind of a smalltalk class browser and a very clever
interface to find the right method with as less as possible shortcuts.
So any ideas here would be very helpful.


--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ru...
CTO Scriptolutions Ruby, PHP, Python IDE 's

Vincent Foley

3/30/2005 2:45:00 AM

0

I don't know if people who develop FreeRIDE, ArachnoRuby or other
IDEs/text editors that want to include intellisense know Smalltalk, but
the eCompletion
<http://homepage.mac.com/monique_bakker/squeak/eCompletio...
"add-on" (for lack of a better word) available in Squeak is quite nice.
Maybe it could be a source of inspiration for Ruby IDE developers.

Vincent

P.S: Lothar, I'm interested by your choice of language for ArachnoRuby;
it's the first Eiffel software (that I know of) that I've used. Any
reason for going with Eiffel instead of something more dynamic like
Ruby|Python|Smalltalk|Lisp? How's developing with Eiffel too? Thanks
for the insights.

Eric Hodel

3/30/2005 5:01:00 AM

0

On 29 Mar 2005, at 17:35, Lothar Scholz wrote:

> Hello Adelle,
>
>> It has been said that features like "intellisense" or "autocomplete"
>> are
>> difficult to implement for dynamic languages such as Ruby.
>>
>> I'd be happy with an IDE that let me choose a .rb file per project,
>> let's
>> call it "environment.rb" which would usually be a list of "require"
>> statements which would establish a run-time state that would be a fair
>> approximation of what classes and methods would be available to 90%
>> of my
>> application.
>>
>> I mean, sure, dynamic languages let us add/remove classes variable and
>> methods anytime we like, but during the first moments of my
>> application's
>> startup I usually set up 90% of the classes that I will need during
>> the
>> remainder of the program's execution.
>
> The difficult thing is not really gathering of information. It is the
> way how do you want to present the thousands of methods
> found in your files and the runtime library.
>
> Since type interference is quite impossible the only solution i came
> up is some kind of a smalltalk class browser and a very clever
> interface to find the right method with as less as possible shortcuts.
> So any ideas here would be very helpful.

Uh....

Where exactly does type inference come in for an auto-completion
feature for an IDE?

Something so heavyweight as type inferencing is unnecessary for doing
90% of the work of figuring out what the likely completions for a
particular chunk of code you're writing.

It would be far easier to just run etags over all the files you require
and use those for auto-completion purposes.

vim has a workable solution for this (and I'm told emacs' solution is
nearly, if not actually, identical), it simply auto-completes words
that have the same beginning above your current location in the text
before switching to words from other buffers. (So if I typed
b-<TAB>-<TAB>-<TAB> here, I would get 'buffers' then 'before' then
'beginning' as possible completions.)

Extending this by reading files on require lines into etags would be
pretty easy, and you could use some weighted sorting to keep commonly
completed words only a few presses of tab away.

While this won't get an accurate completion every time, you really
don't care. You'll find that 90% of the time the word you want is less
than 3 presses of tab away.

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

Ville Mattila

3/30/2005 5:18:00 AM

0

Eric Hodel <drbrain@segment7.net> writes:

>
> While this won't get an accurate completion every time, you really
> don't care. You'll find that 90% of the time the word you want is less
> than 3 presses of tab away.

Lothar probably forgot that arachno ruby has this feature already 8).
Although it only uses tokens from current buffer only. But you still
get 80% accuracy with that. Autocomplete is bound to control-space.
Speeds up typing considerably.

- Ville

Vincent Foley

3/30/2005 5:19:00 AM

0

Unless I'm misunderstanding what Lothar is saying, there's no way to
give out only the methods that a particular object responds to. In
VisualWorks Smalltalk, when you use completion, you just get a list of
_ALL_ methods defined in the system beginning with your pattern.
There's nothinig in the code to let you know what class a particular
object is.

Lothar Scholz

3/30/2005 5:31:00 AM

0

Hello Eric,


EH> Where exactly does type inference come in for an auto-completion
EH> feature for an IDE?

EH> Something so heavyweight as type inferencing is unnecessary for doing
EH> 90% of the work of figuring out what the likely completions for a
EH> particular chunk of code you're writing.

EH> While this won't get an accurate completion every time, you really
EH> don't care. You'll find that 90% of the time the word you want is less
EH> than 3 presses of tab away.

Unfortunately this is not what people expect, at least when they come
from the Java world. Code Completition is a learning tool not
primarily to save some keystrokes. You slowly learn the available
messages for a class while writing your code. Therefore a much better
way then showing a huge list with hundrets of strings list should be
available.

And methods have the heuristic that they share a common
prefix and differ only the last characters. This makes your
(emacs/vi) completition even more useless.

Thats why for example Wing IDE for python is so successful. They even
encourage their users to use type asserts, which is IMHO a good thing.
As a result they can show some precise information.


--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ru...
CTO Scriptolutions Ruby, PHP, Python IDE 's

Adelle Hartley

3/30/2005 5:51:00 AM

0

Hi,

> The difficult thing is not really gathering of information.
> It is the way how do you want to present the thousands of
> methods found in your files and the runtime library.
>
> Since type interference is quite impossible the only solution
> i came up is some kind of a smalltalk class browser and a
> very clever interface to find the right method with as less
> as possible shortcuts.
> So any ideas here would be very helpful.

I'm writing code against an ORM layer, so the attributes of my object
variables are defined in my database schema, not in my source code.

I think the IDE needs to be running a Ruby debugger and capture it's state
(which variables, constants, classes, methods, etc are 'visible' at a
particular point).

The problem with this approach is that when examining a particular line of
code, there may be several routes by which one might reach that line of code
at run-time.

My suggestion presupposes the use of a debugger (which would pick up classes
and attributes that my ORM layer gets from the database), but rather than
having it execute my application, having it execute the first part of my
application (where 90% of my classes are defined) and then stop before my
application actually does anything.

The IDE would take its table of classes+attributes from state of the
debugger, and then combine that with any local definitions in the
file/module/class that I'm working on.

Adelle.

Eric Hodel

3/30/2005 6:00:00 AM

0

On 29 Mar 2005, at 21:00, Eric Hodel wrote:

> It would be far easier to just run etags over all the files you
> require and use those for auto-completion purposes.
>
> vim has a workable solution for this (and I'm told emacs' solution is
> nearly, if not actually, identical), it simply auto-completes words
> that have the same beginning above your current location in the text
> before switching to words from other buffers. (So if I typed
> b-<TAB>-<TAB>-<TAB> here, I would get 'buffers' then 'before' then
> 'beginning' as possible completions.)
>
> Extending this by reading files on require lines into etags would be
> pretty easy, and you could use some weighted sorting to keep commonly
> completed words only a few presses of tab away.
>
> While this won't get an accurate completion every time, you really
> don't care. You'll find that 90% of the time the word you want is
> less than 3 presses of tab away.

Also, this[1] or something similar could probably get you those hints
you need, and again be accurate 90% of the time.

http://www.chadfowler.com/index.cgi/Computing/Program...
TypeWatching.rdoc,v

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

Eric Hodel

3/30/2005 6:29:00 AM

0

On 29 Mar 2005, at 21:30, Lothar Scholz wrote:

> Hello Eric,
>
>
> EH> Where exactly does type inference come in for an auto-completion
> EH> feature for an IDE?
>
> EH> Something so heavyweight as type inferencing is unnecessary for
> doing
> EH> 90% of the work of figuring out what the likely completions for a
> EH> particular chunk of code you're writing.
>
> EH> While this won't get an accurate completion every time, you really
> EH> don't care. You'll find that 90% of the time the word you want is
> less
> EH> than 3 presses of tab away.
>
> Unfortunately this is not what people expect, at least when they come
> from the Java world. Code Completition is a learning tool not
> primarily to save some keystrokes. You slowly learn the available
> messages for a class while writing your code. Therefore a much better
> way then showing a huge list with hundrets of strings list should be
> available.

Have you used Readline tab completion in irb? It is far from useful,
giving you too many potential completions from too far up the
inheritance tree.

> And methods have the heuristic that they share a common
> prefix and differ only the last characters. This makes your
> (emacs/vi) completition even more useless.

In the cases where I've found methods that share a common prefix, I've
found it rare that I'm actually calling those methods from regular
code. Test::Unit is the best example of this. I have many, many
methods starting with test_ but I never call them.

In the cases in Ruby where there are methods that share a common
prefix, #each comes to mind, I don't see how this is useless at all.

I type ea<tab> and see "each" then I hit tab again "each_line" and
again "each_with_index" which is the one I wanted. I don't see how
that's less useful than the ones I've seen in MS' VB editors.
(Besides, I'd never tab-complete 'each', all but the 'c' is on the home
row of a Dvorak keyboard.)

If you still think its totally useless I'd like to see a series of
keystrokes that show how it falls down.

FWIW, ri says there's the following possible each completions:
Core: #each #each_line, #each_with_index, #each_value, #each_pair,
#each_key, #each_byte, #each_object, #each_pair
Pathname: #each_entry, #each_filename
YAML: #each_document, #each_node
Vector: #each2

You can only get those last 5 by requiring extra libraries.

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

Nospam

3/30/2005 7:03:00 AM

0

Eric Hodel wrote:
> http://www.chadfowler.com/index.cgi/Computing/Program...
> TypeWatching.rdoc,v

It would be nice to see this somehow integrated in IDE's, but this still
means the code needs to be executed somehow before the typehints are
available, not?

Regards,

Peter