Intellisense and the psychology of typing

[andrew.queisser]

Yesterday I typed in some C++ code that called a function with two
ints. Intellisense (auto-complete) helpfully told me that the first
formal parameter was called "frontLight" and the second "ringLight". It
occurred to me that I'm getting some semantic help here on top of the
obvious type safety. It seems to me that the existance of this kind of
support is tied to the static typing nature of C++.

I've always been interested in the psychology behind those heated
"static" vs. "dynamic" (quotes to avoid another lengthy discussion
about manifest, latent, explicit, ...) typing debates. So I googled
"Intellisense static dynamic typing" and tried to get a view of the
collective mental landscape of this subject. It appears that the
threads that talk about Intellisense soon run dry. I'm wondering if
this is because:

1) Intellisense is really just another crutch that does more harm than
good? There were a few hardcore defenders of this position but not
many.

2) Intellisense is really useful but hard to implement well in IDEs for
dynamic languages? Can anyone comment on the status of
Intellisense-like tools for dynamic-language IDEs?

3) Users of dynamic languages are always developing/debugging running
programs where the current type of a variable is known and hence
Intellisense is possible again? My own limited experience with dynamic
languages (Ruby) is limited to edit-run cycles.

Any opinions?

Thanks,
Andrew

 

[Thomas Adam]

1) Intellisense is really just another crutch that does more harm than
good? There were a few hardcore defenders of this position but not
many.

I'm indifferent. It depends what mood I'm in as to whether it is useful
or not -- and invariably I tend not to use it, if only because, being
the author, I know what formal parameters most methods expect.

2) Intellisense is really useful but hard to implement well in
IDEs for dynamic languages? Can anyone comment on the status of
Intellisense-like tools for dynamic-language IDEs?

It isn't easy -- just look at what CEDET[1] do, and you'll soon see the
headache involved in using it with EMACS. There's strong talk of
intellisense being introduced into Vim7, and it does already exist in a
limitied capacity with "cream"[2], but only for a particular filetype,
that I can determine.

Of course, in the case of ruby, where ambiguity tends not to matter, how
would you distinguish between:

puts "hello there, how are you", "I'm fine"

and:

puts ("hello there, how are you", "I'm fine")

... it is not as easy as you'd think.

3) Users of dynamic languages are always developing/debugging running
programs where the current type of a variable is known and hence
Intellisense is possible again? My own limited experience with dynamic
languages (Ruby) is limited to edit-run cycles.

Depends on the programmer.

-- Thomas Adam

[1] http://cedet.sourceforge.net/
[2] http://cream.sf.net

 

[sp1d3rx]

my opinion is that if you find it useful, use it. if you don't then
don't... either way, its up to you to decide what's useful and what's
not. don't ask us. Try it out yourself.

 

[Curt Hibbs]

Yesterday I typed in some C++ code that called a function with two
ints. Intellisense (auto-complete) helpfully told me that the first
formal parameter was called "frontLight" and the second "ringLight". It
occurred to me that I'm getting some semantic help here on top of the
obvious type safety. It seems to me that the existance of this kind of
support is tied to the static typing nature of C++.

I'm all for intelligent help. But I just wanted to point out that this
particular example has nothing to do with static typing. "frontLight"
and "ringLight" were parameter names. Any language that has named
parameters could do this regardless of whether or not those parameters
were typed.

Curt

 

[Lothar Scholz]

Hello andrew,

aqhc> 1) Intellisense is really just another crutch that does more harm than
aqhc> good? There were a few hardcore defenders of this position but not
aqhc> many.

When doing wrong (showing wrong types, obmitting methods, adding wrong
methods) it might harm more then being good.

Intellisense has 2 completely different use cases:

a) Reducing typing overhead.
This is easy to implement

b) Learning the API.
This is the real hard one.

aqhc> 2) Intellisense is really useful but hard to implement well in IDEs for
aqhc> dynamic languages? Can anyone comment on the status of
aqhc> Intellisense-like tools for dynamic-language IDEs?

for use case (a) it is implemented in a few IDE's/Editors
for (b) nobody came up to a useable implementation upto now. I don't
think that the JEdit latest plugin is so useful for people who want to
do (a) or (b).

Intellisense is usefull without doubt. But it is to 90% a feature of
static typed languages.

aqhc> 3) Users of dynamic languages are always developing/debugging running
aqhc> programs where the current type of a variable is known and hence
aqhc> Intellisense is possible again? My own limited experience with dynamic
aqhc> languages (Ruby) is limited to edit-run cycles.

No you must check your understanding of program runtime and editing time.

 

[Lothar Scholz]

Hello Thomas,


TA> I'm indifferent. It depends what mood I'm in as to whether it is useful
TA> or not -- and invariably I tend not to use it, if only because, being
TA> the author, I know what formal parameters most methods expect.

Intellisense is most useful for the case where you use libraries or
modify/extend code that you don't have written (aka multi person
projects).

Sometimes i think that the missing typeing eats up very much of the
time that is saved by being typeless as Code is much harder to read
and understand. That's why i simply can't understand people who are
against "optional" type declarations.

 

[andrew.queisser]

I'm all for intelligent help. But I just wanted to point out that this
particular example has nothing to do with static typing. "frontLight"
and "ringLight" were parameter names. Any language that has named
parameters could do this regardless of whether or not those parameters
were typed.

Curt

But only if the receiver and the types of the arguments of the function
call can be resolved. In my case it was the class LightController but
in a dynamic language the call might be ambiguous.

Andrew

 

[Rob .]

Andrew, code auto-completion is not tied to static typing. Your search
for 'IntelliSense' (a Microsoft trademarked term) might not find all
relevant discussions, try auto completion, code completion or method
completion.

My efforts to implement code completion in the Ruby Editor Plugin for
jEdit have been successful to date. Currently the plugin supports
type-based method completion for the Ruby core types, using a naive
variable type detection algorithm. Implementation work hasn't been too
hard, just time consuming.

The plugin's documentation viewer window displays documentation for
your current selection on the method completion popup. My personal use
of the plugin's method completion has mainly proved useful in helping
me learn Ruby APIs.

Future improvements to the plugin will allow the user to select RDoc
they want to import. The imported RDoc will be displayed in the
documentation viewer, and also be used to show additional methods in
the completion popup. So for example you'd be able to import the Rails
RDoc and then autocomplete Rails methods.

http://www.jedit.org/ruby/ - jEdit's Ruby Editor Plugin

Rob

 

[Austin Ziegler]

Sometimes i think that the missing typeing eats up very much of the
time that is saved by being typeless as Code is much harder to read
and understand. That's why i simply can't understand people who are
against "optional" type declarations.

Because I don't want foo to only accept String objects. Suggestions
have been made for applying this information as metadata for the
purposes of parameter suggestions and RPC mapping, but they never seem
to take off very much. Something like:

param :bar =3D> :String
return_as :String
def foo(bar)
bar.upcase
end

Yes, it's more typing. No, it doesn't restrict my code at all.

-austin
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[Ara.T.Howard]

Hello Thomas,



TA> I'm indifferent. It depends what mood I'm in as to whether it is useful
TA> or not -- and invariably I tend not to use it, if only because, being
TA> the author, I know what formal parameters most methods expect.

Intellisense is most useful for the case where you use libraries or
modify/extend code that you don't have written (aka multi person projects).

Sometimes i think that the missing typeing eats up very much of the time
that is saved by being typeless as Code is much harder to read and
understand. That's why i simply can't understand people who are against
"optional" type declarations.

do you really think so in the general case?

i think things like

j = (char (*)[20]) malloc( 20 );

and

char * const *(*next)();

and

int (* foo())[]

take a considerable amount of time to read - at least for me.

scroll way down to see explanations of above - i'm curious how long it might
take people to de-code them.

in the end i've decided that there are only two reasonable forms of typing:
dynamic (a la ruby) or strong and automatic (a la ml langs). other kinds are
evil IMHO.

that being said i'm not against optional typing - but coding the compiler to
understand all of them can be tricky unless it's just simplistic. eg. how
would you like to declare, in ruby, a that takes a string parameter, and a
hash of strings to arrays of int as args? and, if you would only say 'proc' -
then what good is that typing system?


hash = { 'key' => [42] }

block = lambda{|string, hash| p hash[string]}

#
# how to declare callback?
#
callback = block

callback[ key ]

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple. My religion is kindness.
| --Tenzin Gyatso
===============================================================================























explanations:
1) j is a pointer to a freshly malloc'd array 20 of char
2) next is a pointer to function returning pointer to const pointer to char
3) foo is a function returning pointer to array of int

man cdecl

 

[Lothar Scholz]

Hello Ara.T.Howard,

ATH> On Fri, 27 May 2005, Lothar Scholz wrote:

ATH> i think things like
ATH> j = (char (*)[20]) malloc( 20 );
ATH> and
ATH> char * const *(*next)();
ATH> and
ATH> int (* foo())[]

ATH> take a considerable amount of time to read - at least for me.

Taking a specific not very good implementation might not be a good
argument for or against a general feature. If you have choosen Eiffel or even
lisps (the ....) code, the type declaration might look much better.

And when i say optional i don't mean to document each type. 90% of the
types are simple class names (yes i know many rubyists don't like it
to call classes types).

ATH> in the end i've decided that there are only two reasonable forms of typing:
ATH> dynamic (a la ruby) or strong and automatic (a la ml langs). other kinds are
ATH> evil IMHO.

I like Lisp. Sometimes at least.

ATH> that being said i'm not against optional typing - but coding the compiler to
ATH> understand all of them can be tricky unless it's just simplistic. eg. how
ATH> would you like to declare, in ruby, a that takes a string parameter, and a
ATH> hash of strings to arrays of int as args? and, if you would only say 'proc' -
ATH> then what good is that typing system?

I don't want a (complete) typing "system". If it gets complicated
change your app or don't use the optional type hints.

If my IDE could use it or the YARV JIT-Compiler could produce more productive
code for some methods it is enough.

I think that step of pragmatism is what very very few people until now
really understands. Maybe it takes a few years of Lisp experience to
see the value of typing hints.

 

[EventHelix.com]

Intellisense does improve programmer productivity as
you do not have to keep opening header files to refer
to the interfaces. In VC++ the intellisense display
also shows the function header comment, so you have
full access to the information about the interface.

Deepa

 

[Brian Beck]

Well, there are two distinct features of IntelliSense as you know it.
One is auto-completion and the other is contextual help.

Auto-completion is included almost all beefy Python IDE's.

Contextual help is included even in IDLE, where if you begin typing a
function call, its docstring pops up around where you are typing.
Since many functions have dynamic arguments, I think this really is the
best solution, since the implementor of the function knows what would
be the most helpful to show. Open the interactive IDLE prompt and type
max(, iter(, help(, for example -- although most of those are pretty
minimal.

 

[James D Carroll]

1) Intellisense is really just another crutch that does more harm than
good? There were a few hardcore defenders of this position but not
many.

I'm primarily a VB programmer, but I also do Java and web stuff as well.
Whenever I look at a new IDE the FIRST thing I look at is whether
Intellisense-like functionality is present. If it is not, I discard it from
further consideration. The reason has nothing to do with static vs dynamic
typing. It has to do with the fact that I spend a considerably amount of
time thinking about how I'm going to solve the problem at hand. Filling my
head with API specs that I have to look up is just a pain. And frankly if I

2) Intellisense is really useful but hard to implement well in IDEs for
dynamic languages? Can anyone comment on the status of
Intellisense-like tools for dynamic-language IDEs?

It might be and probably is. But I say if dynamic typers want the
flexibility they think they are getting then they should have to deal with
ALL of the consequences.

3) Users of dynamic languages are always developing/debugging running
programs where the current type of a variable is known and hence
Intellisense is possible again? My own limited experience with dynamic
languages (Ruby) is limited to edit-run cycles.

I can't speak to that only to say that, how in the world can an object that
accepts anything reasonable be expected to protect itself from misuse or
provide reliable services given a set of parameters?

 

[Lothar Scholz]

Hello James,

JDC> I'm primarily a VB programmer, but I also do Java and web stuff as well.
JDC> Whenever I look at a new IDE the FIRST thing I look at is whether
JDC> Intellisense-like functionality is present. If it is not, I discard it from
JDC> further consideration. The reason has nothing to do with static vs dynamic
JDC> typing. It has to do with the fact that I spend a considerably amount of
JDC> time thinking about how I'm going to solve the problem at hand. Filling my
JDC> head with API specs that I have to look up is just a pain. And frankly if I
JDC> have to type 'boolean' instead of 'boo<tab>' I get real cranky real fast.

Yes you come from static typed languages, so you have to learn
things are different in dynamically typed languages.
JDC> It might be and probably is. But I say if dynamic typers want the
JDC> flexibility they think they are getting then they should have to deal with
JDC> ALL of the consequences.

The most normal consequence is that there is no intellisense. Thats
how we deal with it at the moment - and yes i agree with you that this
is not a positive consequence.

JDC> I can't speak to that only to say that, how in the world can an object that
JDC> accepts anything reasonable be expected to protect itself from misuse or
JDC> provide reliable services given a set of parameters?

Many people will argument that typing errors are far less common then
one would expect at the first time when comming from a static typed
language. I don't know about large systems in Ruby but there are a few
really large SmallTalk programs out there and they work fine.

 

[Lurker]

if I have to type 'boolean' instead of 'boo<tab>' I get real cranky real

fast.

Why? Is your programming speed really limited by the difference
between typing "lean" and hitting <tab>? If typing speed is
the limitation - go get some touch-typing courses.

 

[Michal 'hramrach' Suchanek]

fast.

Why? Is your programming speed really limited by the difference
between typing "lean" and hitting <tab>? If typing speed is
the limitation - go get some touch-typing courses.

Touch-typing is good (and I should also learn that but it's always
easier to mistype "lean" than a tab

Michal Suchanek

 

[ES]

fast.

Why? Is your programming speed really limited by the difference
between typing "lean" and hitting <tab>? If typing speed is
the limitation - go get some touch-typing courses.

Oh, now. If we estimate that a decent programmer writes about 60
words per minute and that 'lean' is about 60% of the word 'boolean';
this would mean that the same decent programmer could write approx.
100 'leans' per minute (or that one 'lean' takes about 0.6 seconds
to write). If we further assume that pressing the <tab> key takes
slightly longer than any other letter, we can still extract a time
savings of about 0.45 seconds per boo<tab>. A single source file
may contain, say, 7 instances of the word boolean on average and
an average project could contain 10 source files; a single project
for one iteration would then yield a savings of about 31.5 seconds.
Extrapolating from the average programmer's involvement in about
three or four projects per year and perhaps two iterations each,
we approach the much more significant figure of about 4 minutes
per year! Extending tab-completion to other keywords and method
names as well could clearly yield significant productivity gains,
not to mention the time lost by the CPU during that typing cycle.
If we assume a utilization rate of about 60% for a CPU, each <tab>
per boolean could mean, on an average computer, saving the CPU about
675,000,000 idle cycles or 357,750,000,000 idle cycles per year!

Now, if an average programming language has 20 keywords and each
appears at a ratio relative to the boolean (on average), a given
source file would have a total of around 140 keywords, that is
1400 per project and thus 9600 per year resulting in a savings
of over an hour!

Then, if you take into account time wasted by the programmer on
silly rebuttals to completely irrelevant topics on Usenet...

E

 

[Vincent Foley]

I have rapidly skimmed over the few responses here. Auto completion is
definitly possible in dynamic languages: Common Lisp has it with its
Emacs mode, SLIME.

If you're in a slime buffer, you type (get-un then press C-c Tab and
Emacs will auto-complete with (get-universal-time), if there are many
choices, they will be displayed in a split window, if the function
takes parameters, those will appear in the mini-buffer, like so:

(with-open-file (stream sb-impl::filespec &rest sb-impl:ptions) &body
body)

SLIME is also not the only place where a dynamic language has
auto-completion, check out Ecomplete in Squeak or the auto-complete
package in Visual Works Smalltalk. It can be done, maybe not as easily
as in a statically typed language, but it definitly can be done.

 

[Lothar Scholz]

Hello Vincent,

VF> I have rapidly skimmed over the few responses here. Auto completion is
VF> definitly possible in dynamic languages: Common Lisp has it with its
VF> Emacs mode, SLIME.

VF> If you're in a slime buffer, you type (get-un then press C-c Tab and
VF> Emacs will auto-complete with (get-universal-time), if there are many
VF> choices, they will be displayed in a split window, if the function
VF> takes parameters, those will appear in the mini-buffer, like so:

When using procedural code it is easy and not comparable with autocompletition for Ruby.