[IDE features]

Richard A. O'Keefe ok@atlas.otago.ac.nz
Tue, 2 Feb 1999 11:41:45 +1300 (NZDT)


Someone suggested that an IDE should try to perform all the necessary
changes when you modify a program.

Someone else said
	
	Well, that's a case of one man's meat, another man's poison. I never
	expected any IDE to perform these tasks for me.

Way back in the 70s, the Interlisp philosophy was

	A Program Is Not A Listing!

To be sure, Interlisp stored program sources in almost-readable text files,
but there were all sorts of tables in there that made it a data base of
sorts (e.g. it could load one function from a source file without even
_reading_ the rest of the file).  In particular, indentation was
completely under the control of the system (modulo a few variables):
while editing, text was regenerated from richer data structures.

However, one lesson from that is that even when you have a tool called
DWIM (Do-What-I-Mean) you can't always tell what that is.

Suppose a programmer moves a function from one module to another
(the example that began this thread).  Does that mean that the
code in the original module should be modified, or was it simply
the first step in _replacing_ the function with a new definition
in the _same_ module?

Suppose a programmer switches the order of two arguments of the
same type.  Should that code that calls that function be modified,
or is the programmer correcting an error?

You can only provide an "intensional" IDE if you stop regarding the
textual form of a program as primary, and provide editing facilities
that distinguish between "CHANGE INTERFACE" (so the argument order
in the callers should change) and "CORRECT IMPLEMENTATION" (so the
argument order in the callers should not change).

Then of course there are the changes that the IDE *cannot* figure
out.  If I edit a function and change the type of one of the
parameters, what should the IDE do about the callers then?  The
best it can do is _find_ all the callers (in Interlisp:
.EDIT WHERE ANY CALLS <function name>
) and give you the chance to change them.

Now that _is_ something that one could reasonably expect from an
IDE, and the UNIX 'cscope' command (modelled loosely the Interlisp
MasterScope component) provides it for C.

What _I_ want from an IDE is a language that is so simple to parse
that it is easy to build tools for (I'm currently trying to build
a cross-reference program for TCL, that's impossible, so I have
to approximate, and it appears to require O(N**2) time worst case
simply to parse a TCL file) and an IDE that is easy to plug tools
into.  The best environment I have for Clean is the UNIX one where
I can use Emacs; the Clean IDE editor on the Mac is so _crippling_.
I'd rather the Clean team spent effort on the compiler and libraries,
not the IDE, which is one reason why open sources might be in
everyone's benefit.  Someone with better ideas about an IDE would
be able to try them out and offer them back.