Towards a better IDE in Squeak

Hi all,

I'm currently doing a PhD under the supervision of Stephane Ducasse and
Oscar Nierstrasz at the university of Bern, Switzerland. My main
research interests are in the context of Integrated Development
Environments (IDEs). I'm planning to work on the Squeak IDE to see how
the IDE of a dynamic object-oriented programming language can be
improved and extended.
Especially, I want to experiment with different metaphors to browse and
navigate source code, with new metaphors to present static (i.e.,
classes, methods, source code) as well as dynamic aspects (i.e.,
objects, relationships between objects, etc.) of a program in the same
IDE, with new ways to modify and edit source code, etc.
I believe that we can do more in a better way these days than what we
have in the current IDE in Smalltalk or in Java. I believe that the IDE
of the future can help the programmer to program more efficiently and
with less errors by giving him more insights into the program being
developed or by providing him with better tools and guides during his
daily work. I believe that what we have now as IDEs are far away from
what is possible to have and even far away from what we actually need to
be effective and efficient in our daily work. This is a bit sad for
Smalltalk, because a long time ago it had the best IDE, but now Eclipse
is getting better and better while the IDE of Smalltalk / Squeak stays
more or less the same. During my PhD I want to see how we can get
something better out of the current Squeak IDE.

I write this message out of two reasons: First, I would like to know if
you have ideas for things that are missing in the current DIE of Squeak,
"things", tools, metaphors, ideas that you would like to see
implemented. What are your ideas of how an IDE could help you to work
more efficiently in your daily work? Where is the current IDE in your
way, where is it not good enough, what could be better? What do you
miss, what do you need to get a better IDE?

Second, I would also like to do kind of empirical studies in the future
to somehow validate the effectiveness and efficiency of new approaches
for an IDE, hence I need subjects performing some experiments in these
future IDEs and I also need data about how you use your IDE (e.g., how
you browse source code, how and where you write source code, with which
tools, etc.). Will you be willing to provide me with these data recorded
by some non-invasive recordings tools you can simply load in your image
and which will then save the recorded data to a file which you would
then send to me? Are you also willing to perform some experiments in new
IDEs, e.g. trying and playing with them, use them for a project of
yours, etc.?
For me it is important to know if I can motivate enough people to do a
serious empirical study. Without that, I would have a hard time to
"prove" that a new approach to e.g. navigate source code is indeed
useful and promising, because this is very much dependent on personal
feelings and impressions. Only a broader study can hence "prove" the
general usefulness (or uselessness) of such a new approach or metaphor.

Thanks for your help.

Kind regards,
David

Hello David,

DR> Especially, I want to experiment with different metaphors to browse and
DR> navigate source code, with new metaphors to present static (i.e.,

I' very much interested.

DR> for an IDE, hence I need subjects performing some experiments in these
DR> future IDEs and I also need data about how you use your IDE (e.g., how
DR> you browse source code, how and where you write source code, with which
I'm willing to have some tool watch me coding (maybe it will even
laugh at times).  I'd have to look at the records before I send them
to have my customers trust that I don't give away their secrets.

I'm not a programmer but an engineer (kinda MSEE) and I'd like to have
a tool that gives me a grasp on an algorithm.

Browsers are bad in this, source files also. The best thing I have now
is Chris Mullers TracingMessagesBrowser but it's too cumbersome to
fill the list and to remove from the list if I add implementors of a
message with a name everybody uses.

So maybe use MessageTally>>spyOn: to fill a TracingMessagesBrowser.
That with an easy to prune autoFilled list of classes whose methods
I'm interested in.

And combine that with *initialized* objects, sampleInstance is no help
as it doesn't present Objects in use. That's (now that I think of it)
the thing that might have brought me away from Trygve's BabySRE.

Things must be quick for I often find myself closing the windows I
just opened to give me a certain view, just because I find out I need
a different view.

Thanks for bringing up the subject, so I could examine my own style of
work.

Good Luck with your thesis!

Herbert                            mailto:[hidden email]

Hi David,
Excellent! You seem to have similar goals to my goals for the BabuUML
project.  An  up to date report on the current project state  will be a
chapter in a forthcoming book on SE research. You may find it
interesting to look at a late draft:
   http://folk.uio.no/trygver/2007/babyUML.pdf

All the best for your project
--Trygve

On 18.02.2007 20:31, David Röthlisberger wrote:
--

Trygve Reenskaug      mailto: [hidden email]
Morgedalsvn. 5A       http://folk.uio.no/trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

Hi David,

I think you might find some work by Andrew Black and myself interesting.
It mines some existing patterns from Smalltalk and modern extensible
IDEs such as Eclipse (and proposes some new ones) for representing code
models. The main goal is to make code analyses reusable objects so that
they can be leveraged by different tools (or views), without sacrificing
performance.

We don't have a current version up on the web at the moment, mail me
offline if you're interested.

Daniel Vainsencher

David Röthlisberger wrote:

     Hi David,

    Your mail comes at the right time! I share your needs for
empirical studies of programmer's usage of the IDE, and I am going to
release an updated version of my
IDE monitoring tool (called "SpyWare" ;-) ) in the next few days.

I think we could join forces and share data. Incidentally, I am going
to Bern at the end of this week to meet some people at SCG... If
you're around we can discuss and compare
our needs. Feel free to reply on or off-list.

    Cheers,
         Romain

On 2/18/07, David Röthlisberger <[hidden email]> wrote:

2007/2/18, David Röthlisberger <[hidden email]>: Most things in this list are either taken form other IDEs or bugfixes,
so they might not be interesting from a research point of view:

- Scoping of implemtors/senders to packages
- make class extensions work like in VW
- make the submethod display more than just a text string. Why can't
SLint just underline the code that violates a rule?
- run SLint on a method once it is compiled (for error reporting see above)
- bring Refactoring Engine to the point where the Eclipse Refactoring
Engine is (code formatting and stuff)
- a protocol browser that is actually usable (choose upper bound)
- multiselection (including nil-selection)
- make drag and drop work everywhere in the browser
- make multiselection work with drag and drop
- fix those annoying bugs in the browser where a method ends up in the
wrong category (if you are lucky) when you are editing the same class
in two browsers
- fix the debugger (those annoying cases where you code ten minutes in
the debugger accept it but the code lost because you where in a block
or whatever)
- "move to class/instance side" refactoring (yes I know this is
technically not a refactoring, I don't care)
- roel typer integration to display the "roel types" of variables
- when changing the shape of a class only recompile the methods that
actually access instance variables
- method display plugins (eg. a profiler can draw a heatmap but just
coloring the statements differently without the need to implement the
whole index <-> statement mapping)
- a better inspector that supports drag and drop and where you can
drop objects in the evaluator pane
- back-button
- "make trait" refactoring (working together with multiselection)
- trait support for refactoring engine
- finish the traits browser
- what is is the status of services to enable refactoring support in
the omnibrowser? It it is not done then do it.
- integrate services into the duo-systembrowser

Cheers
Philippe

> - make the submethod display more than just a text string. Why can't
> SLint just underline the code that violates a rule?

SLint actually does select the part that produced the match (at least
when you run it from my SUnit Lint integration tool), to see it you
have to move the mouse over the text pane however.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

On Feb 18, 2007, at 11:31 AM, David Röthlisberger wrote:


> I write this message out of two reasons: First, I would like to  
> know if you have ideas for things that are missing in the current  
> DIE of Squeak, "things", tools, metaphors, ideas that you would  
> like to see implemented. What are your ideas of how an IDE could  
> help you to work more efficiently in your daily work? Where is the  
> current IDE in your way, where is it not good enough, what could be  
> better? What do you miss, what do you need to get a better IDE?
>

Using OmniBrowser for the last few years has made me notice something  
interesting. I did a lot of work in VW, and came to depend heavily on  
the power of the RB for getting things done efficiently. On the other  
hand, in Squeak I was using OB, and had to work around the lack of  
refactoring support. What I found is that having the right browsing  
UI can make the high-level operations that the RB provides less  
essential.

Here's a slightly contrived example, but it mirrors the sort of  
situation I've often found myself in with OmniBrowser. Lets say I  
have a class that has coordinate data in it, stored in ivars x and y.  
I want this to be private, so I don't have accessors. Now say I  
decide to convert the internal storage to polar coordinates.

With the RB, I'd probably do something like this:

1 apply the 'abstract variable' refactoring to create accessors and  
convert all direct accesses to messages
2 create instance variables r and t and reimplement the accessors in  
terms of r and t
3 remove the instance variables x and y
4 browse the senders of #x and #y and modify them to use r and t  
directly
5 remove the accessors for x and y

That "abstract variable" refactoring is really handy, because I can  
keep the class functional the whole time (particular handy if I'm  
developing using tests). On the other hand, I have to bounce around  
in the browser a lot, and I'll probably have to have several  
"senders" browsers open at once.

Now, in OmniBrowser I don't have that refactoring, but I do have a  
"chase variables" browser. It shows me a list of variables, the  
methods that access them, their senders, the senders of the senders  
and so on. So what I'd do is this:

1 create instance variables r and t
2 look at all the writers of x and y and modify them to write to r  
and t as well.
3 look at all the readers of x and y and modify them to read from r  
and t instead
4 make the writers of x and y write only to r and t
5 remove x and y

What's nice about the "chase variables" browser is that it makes step  
3 pretty easy, because removing the uses of x and y usually also  
involves modifying the senders of those methods and maybe their  
senders as well. The "chase variables" browser shows me the  
transitive closure of the methods that use a given variable. This  
means I can see in a very visual way what I have to do, and what I've  
already done. I'm shifting methods from using x and y to using r and  
t, and the browser shows me a pretty direct reflection of that.

The upshot is that I don't miss the "abstract instance variable"  
refactoring much. Having it wouldn't hurt, and I do want to implement  
it, now that Lukas has got the ball rolling. But changing the way we  
can view code is even more powerful, and opens the door to more  
powerful tools. For example, refactorings are great, but they're  
limited in that they have to preserve the semantics of the code. If  
we could easily see what the effects of a particular change were,  
would it be safe to use powerful tools that didn't preserve semantics?

Colin

Hi David,

what's badly missing in "modern" IDEs is the possibility to write  
integrated documentation in form of stories. Having just a 1:n  
correspondence between system category and classes, message category and  
methods, is [in non-trivial cases] insufficient for describing "why and  
how this works" and "what, in terms of entities, is this *all* about" and  
moreover to ask for "what parts of the system have no integrated  
documentation".

I'd like to be able to drag'n'drop links to "browser accessible objects",  
into an integrated document and write a story "around" the links.

Classes, variables, categories, messages, statements, literals, all should  
be accessible by such link.

With integrated I mean, at minimum, that when browsing for senders,  
implementors, variables and other references, then the result list must  
also turn up the integrated documentation (which containes the links as  
described).

Another aspect of the integrated documentation is that it can (must!)  
outdate when, for example, things are renamed or deleted. Imagine a doIt  
for "browse outdated documentation" ;-)

I hope the above was clear; if not then I'd be happy to respond to  
questions and critique.

For the empirical case study: count me in, I'm used to be electronically  
investigated :)

/Klaus

On Sun, 18 Feb 2007 20:31:55 +0100, David wrote:

> Hi all,
>
> I'm currently doing a PhD under the supervision of Stephane Ducasse and  
> Oscar Nierstrasz at the university of Bern, Switzerland. My main  
> research interests are in the context of Integrated Development  
> Environments (IDEs). I'm planning to work on the Squeak IDE to see how  
> the IDE of a dynamic object-oriented programming language can be  
> improved and extended.
> Especially, I want to experiment with different metaphors
...
> For me it is important to know if I can motivate enough people to do a  
> serious empirical study.
...
> Thanks for your help.
>
> Kind regards,
> David
>
>
>

In fact, we do: http://web.cecs.pdx.edu/~black/publications/ModelExtensions.pdf

Some points I believe to be missing is modern programming environments:

1. Making "why" a property to be populated by the programmer in all
programing artifacts. Like a Jr. programmer, if the "why" property is
not populated, the interface should gently, non-disruptively ask
"why". Some say that the answer to "why" is already in the programming
source code. I rather disagree. Often, even Sr. Programmers experiment
with the code to discover the chosen way that is eventually preserved
for the record in the distribution. However, the learning process
itself, and hence the reason why, is thrown away. "Why" often
documents the code that shouldn't be there, rather than the code that
is. A system without "why" preserved in it can exhibit the problem in
the form of many different programmers submitting a "fix" for the same
"problem" and only told "why" the fix won't work after they went
through the effort of "fixing" it. Reflexive, logic programming
languages like Prolog have the advantage of describing "how" they've
reached some conclusion which is similar to explaining "why".

2. Check out Jef Raskin's book, "They Humane Interface" for some very
insightful observations from a cognitive psychology perspective.

3. Along with "why", I believe "who", "what", "where", "when", and
"how" should be configurable properties of all programming artifacts.
They imply many important questions often left unanswered but are
necessary for understanding and modifying other programmers' code.
These need not be just "text" or "tag" properties, but full fledge
objects and code that can be extracted, examined, programatically
reasoned from, or modified programatically. Something like the
semantic web.

4. Zoomable names/labels. Because programing languages have most often
been expressed in text (for the advantage of the compiler) a lot of
burden has been placed on the meaning of a field name. In fact, and
enormous burden is placed on field names. This fact can by illustrated
by some who need to use Camel Case, Hungarian Notation, quotation
marks for  names with white space, type systems, scoping rules, dot
notation, syntax highlighting, autocompletion lists, name spaces,
globals, method-name/property-name/database-field-name confusion,
defs, source code readability, etc. These names and labels are often
defined far from where they are used placing a burden on the
programmer's memory or spend the programmer's time to jump from one to
the other. Rather, I believe, as long as we program in a _GUI_ we
should allow labels to be dynamically zoomed, in-place, to the level
of detail required by the programmer's memory and experience... any
level of detail. Even after the code is persisted to storage,
subsequent programmers should still have the dynamic freedom to
re-zoom the label to the same degree as the original programmer.

5. Continuous unit testing and integration testing should be built-in
to even the tiniest artifacts of coding so that such things become
visual, automatic, unconscious to the developer. (cf Raskin).

6. I would include audio documentation to be a normal part of source
code documentation. This would be a crutch for the "documentation
writing challenged" among us. Such things could me setup to be
programatically translated to other languages, accents, or dialects.

More later.

Right on. Also, "Interactive Programming Environments" by Barstow  
should be required reading for anyone dabbling in that area (e.g, it  
contains the PIE paper). I saw it for 85 cents recently at Amazon,  
everyone seems to think "old" computer books are worthless ... sigh ...

- Bert -

On Feb 19, 2007, at 8:45 , Darius Clarke wrote:

Hi Daniel

> I think you might find some work by Andrew Black and myself interesting.
> It mines some existing patterns from Smalltalk and modern extensible
> IDEs such as Eclipse (and proposes some new ones) for representing code
> models. The main goal is to make code analyses reusable objects so that
> they can be leveraged by different tools (or views), without sacrificing
> performance.

yes, thanks, I already read your and Andrew Black's paper "A
Pattern Language for Extensible Program Representation" (Stef gave it to
me :).
It contains very interesting and useful patterns and ideas, I liked it.

David

Hi Romain,


>    Your mail comes at the right time! I share your needs for
> empirical studies of programmer's usage of the IDE, and I am going to
> release an updated version of my
> IDE monitoring tool (called "SpyWare" ;-) ) in the next few days.

Cool!
I also did some work on SmallBrother - a tool of Roel Wuyts initially
implemented in VW to record the programmer's usage of the IDE. It's now
also available for Squeak on SqueakSource and can spy most of the user's
action occurring in OmniBrowser.

> I think we could join forces and share data. Incidentally, I am going
> to Bern at the end of this week to meet some people at SCG... If
> you're around we can discuss and compare
> our needs. Feel free to reply on or off-list.

yes, I'm here, so we should indeed discuss! Especially, I'm interested
in how you find your subjects using and experimenting with your tools.
Adrian Kuhn is also doing something similar in VW, but you probably know
that already.


David

Hello Klaus,


Thanks, this is a very interesting point! Having that would be indeed
useful and of great value.
I will add this point to my list.


> For the empirical case study: count me in, I'm used to be electronically
> investigated :)

Thanks, I appreciate. :)


David

Hi!

While mentioning "neat things we could do" with the Squeak environment I
would like to mention two of my ideas:

1. The Magic book. It is described on the Swiki IIRC. The base idea is to
use unit tests to associate code with documentation and then monitor how
the unit tests change in order to invalidate documentation.

2. The "developer events" idea with publish/subscribe of events together
with a p2p network to create "real time collaboration".

Feel free to email in private for more details. Or dig out my previous
posts in the archives :).

regards, Göran

This msg didn't seem to get through. My apologoes if it did.
Cheers
--Trygve
==================================================================

Hi David,
Excellent! You seem to have similar goals to my goals for the BabuUML
project.  An  up to date report on the current project state  will be a
chapter in a forthcoming book on SE research. You may find it
interesting to look at a late draft:
   http://folk.uio.no/trygver/2007/babyUML.pdf

All the best for your project
--Trygve

On 18.02.2007 20:31, David Röthlisberger wrote:
--

Trygve Reenskaug      mailto: [hidden email]
Morgedalsvn. 5A       http://folk.uio.no/trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

2007/2/18, David Röthlisberger <[hidden email]>:
> more efficiently in your daily work? Where is the current IDE in your
> way, where is it not good enough, what could be better? What do you
> miss, what do you need to get a better IDE?

Hi David,

I have a problem with the multitude of different browsers. I don't
know what the best solution is...
a good window navigation tool like exposé?
transient browsers that you don't need to explicitly close?
one central window with most tools at hand and contextual inspectors?

--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

- sender/implementor widgets with tree for next sender/implementor
- multiple method editing (wishker).
But you know my list and crazy ideas.

Stef

Hi Trygve


> Excellent! You seem to have similar goals to my goals for the BabuUML
> project.  An  up to date report on the current project state  will be a
> chapter in a forthcoming book on SE research. You may find it
> interesting to look at a late draft:
>   http://folk.uio.no/trygver/2007/babyUML.pdf

ok, thanks for this pointer, I'm reading it.

David