Re: What IDE features do we need?

[Mike Mattie <codermattie@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]

On Thu, 24 Apr 2008 10:21:35 -0700
Thomas Lord <lord@emf.net> wrote:

> Eli Zaretskii wrote:
> >>
> >> Refactoring requires a lot more infrastructure than what etags and
> >> ebrowse provide.
> >>     
> >
> > I'm not convinced, but I won't argue.
> >   
> 
> 
> The tools that people are excited about differ from etags and ebrowse
> by virtue of their incremental nature (updating the databases as the
> code is modified) and precision.    The precision aspect is mainly a
> Java thing since the simple (enough) scoping rules and absence of
> syntactic abstraction make incremental parsing tractable.  
> 
> If you were to argue and you argued that the actual software
> engineering practice of refactoring and other correctness-preserving
> global transforms doesn't need such heavy guns, and is very
> well-served by more simply text based tools like Emacs has, etc:
> well, you'd get no argument back from me.

These are not just issues of simple productivity, likening them to
a useful crutch.

These tools are priceless for the fella that is new to a code-base
and needs to learn how the system works. If you wrote a book on
a scale that could not be bound (like the source for a large system)
a standard back-matter preparation would not scale (e.g the index).

semantic like static analysis tools allow the code to be navigated
structurally. If the architecture is clean both humans and
programs can navigate this structure which is quite exciting with
sufficient imagination.

But the vital need for static analysis is clear with the sophisticated 
linkage of large systems, and the fact that vast amounts of C/C++/java
have entered maintenance mode.

To picture a use case imagine the hero consultant squaring off against
a legacy system of COBOL,pascal,C,C++ (standard industry progression layered),
with a deadline to make a correction in the system.

Examples: Y2k, euro conversion.

etags does not cut the mustard in that scenario. Semantic has the potential
to equal the task.
   
> But, afaict from watching people in various communities talk about
> it, Eclipse's Java features have basically /taught/ the utility of
> global transforms to many programmers.   So many people tend to be
> excited about the Eclipse approach and to assume that that's how
> things are supposed to work.

Characterizing re-engineering as a java feature is tempting due to
the iosomorphism of the byte-code/source-code. However static analysis
is a natural response to the rise of sophisticated scoping and linking
that happened a *while ago*. You can argue that such mechanisms are
a response to "human wave" tactics, but the relics of such efforts
are now vital infrastructure.

The right thing for static analysis as the author of CEDET no doubt
discovered is a surprisingly large system, to large to be called a
feature. The right thing gives birth to a number of vital features
however.

The infrastructure required to complete a symbol correctly is the
same infrastructure required to change the storage of a field
and accurately analyze the propagation of that change throughout the
code-base with a measurable margin of error.

The prior art goes all the way back to SCID (source code in database) AFAIK,
and the design convergence is remarkable. I have a architectural design
for an almost identical system independently developed. A second team,
again independent, attacked the problem again and drew the same diagram 6 months 
later. I can bet with high confidence that the proprietary coverity system has
a similar design as well.

So to wrap up everyone ends up drawing the same architecture. CEDET is
a implementation of that high-level architecture. If you can draw a
different architecture and make it work then you should publish
and claim your fame. Otherwise CEDET is a good idea that everyone has
had and few have had the stamina to implement.

Cheers,
Mike Mattie

> 
> 
> -t
> 
> 
> 
> 
> 
> 
> >
> >
> >   
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]