Falling in love with D, but...

[David B. Held]

Bill Baxter wrote:
> [...]
> Isn't that kind of what Smalltalk was supposed to be?  I don't know 
> about the graphical representations of functions part, but at least the 
> main editing required a "SmallTalk Browser" which was basically just a 
> hierarchical explorer for all your bits of code.
> [...]

I'm sure it's not completely different from Smalltalk.  Just browsing 
some screenshots of various Smalltalk implementations, however, I'm not 
particularly impressed.  Probably the closest thing to what I envision 
is the UML editor in one of the implementations.  The key, I think, is 
to understand where you need text for its density and where you want to 
take advantage of the visualization benefits of graphics.

What I am seeing in a lot of the screenshots is something like a 
class/method browser that reminds me too much of formula/query builders 
that you see in business apps designed for novices.  While that has its 
place, I really don't think a good graphical IDE should be a 
hand-holding crutch for noobs.

The other key is having multiple perspectives.  This is something I 
really like about Eclipse.  You can view the code, you can view the 
object hierarchy, you can view the project explorer all at once.  They 
are all views on the same underlying data.  If we extend this to the 
point where you can view the declarations in a class as text or as 
icons, then I think you start to see the benefits going GUI.

For instance, UML is nice when you want to see the high level structure, 
but no good if you need to see the implementation.  That's because UML 
was specifically designed to abstract away the implementation.  So 
basing a GIDE on UML alone would be a mistake.  However, having a UML 
view of your library/app class hierarchy *would* be really useful if it 
also allowed you to zoom in on class/function details.  In fact, having 
a dynamic zoom feature that automatically compressed class definitions 
into UML entities or even just class names at the highest levels and got 
down to data types and code at the lowest would be pretty darned cool, IMO.

Tree-based browsers display packages and modules as lists because that's 
a convenient thing to do in a primarily text-oriented IDE.  But there's 
really no reason to limit the display of such entities as lists.  Being 
able to automatically arrange your modules according to inheritance or 
dependency relationships (or both at once in separate views) would take 
advantage of 2D screen real estate.  Being able to zoom in on the 
dependency view to the point where function call dependencies are 
visualized could make it much easier to understand an unfamiliar 
codebase.  It would also help to see how much coupling you have between 
modules, and how much work is involved in refactoring to eliminate a 
dependency, all of which are important tasks when maintaining a large 
codebase.  This is the kind of capability that I haven't seen in any 
existing products (though admittedly, I haven't looked all *that* hard).

Encoding syntactic information in the text presentation (or with a 
hybrid text/graphical presentation) is also not something I've seen 
anyone brave enough to attempt.  Syntax highlighting + folding is 
generally as far as people take it, but I don't see any harm in trying 
to push the envelope.  I'd love to see an IDE with an integrated TeX 
editor that lets you enter mathematical formulas in the natural format 
and just do the right thing.  It would be somewhat like integrating 
Mathematica/Maple into the IDE, but without all the automated algebraic 
logic behind it.

I think D is still clean enough to support this kind of IDE without too 
much trouble, but macros could make things really interesting (since 
they rely primarily on the text representation of the program...but 
maybe they aren't as much of a problem as I suspect).

Dave