Some more points:

1. Squeak's "Tile" view/representation of source code shows how
programing source code artifacts can be scoped and represented as
objects in and of themselves.

2. The most important point in the Raskin book for your attention is
the fact that the rarest and most precious resource for all software
developers and their organizations, above all other constraints bar
none, and which all code and tools must be designed to conserve is ...
human memory. Due to efficiencies of scale in all other aspects of
software development, to load and copy what's in human memory takes
more time and expense than /anything/ else. Architectures must be
designed around the conservation of human memory at their basis.  Most
programmers just cannot develop photographic memories for all that is
asked of them by almost all architectures and platforms. Time delays
in context switching burns up much of a programmers' time. API calls
are in the 100,000's now and continually changing.

3. As Alan Kay alluded to in his latest interview, a lot of assumed
laws of nature are really traditions we've not question. A lot of
programming artifacts are really efforts to fold information, often
using labels, to fit within the limits of today's monitors and
yesterday's paper. But, as a thought experiment, imagine if we unfold
that information in a 20' x 20' display so we could find what we want
just by moving our eyes. Head mounted and eye mounted displays could
break many of our assumptions about the complexity of code. Many
variable, labels, and other shorthand shortcuts  could be dispensed
with. The mental "chunking" (a psychological term) of data can take on
another form for efficiencies.

More later.

On 2/19/07, stephane ducasse <stephane.ducasse at free.fr> wrote:
> - sender/implementor widgets with tree for next sender/implementor
> - multiple method editing (wishker).
> But you know my list and crazy ideas.
>
> Stef
>
> > 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
> >
>
>
>