Re: About CEDET, Completion, and compilers

[Eric M. Ludlam]

On 03/13/2014 09:40 AM, Andreas Röhler wrote:
> Am 13.03.2014 04:04, schrieb Eric M. Ludlam:
> [ ... ]
> Hi Eric,
>
> yes, CEDET is a very interesting tool.
>
> BTW just reading at SO an answer WRT to IDE's, which IMO also stresses
> the usefulness of further CEDET-development:
>
> http://stackoverflow.com/questions/22372526/integrated-development-environments/22372626#22372626
>
>
> There was a remark in the thread saying something like:
> CEDET provides a toolset, but no-one uses it - beside CEDET itself.

I am familiar with this sentiment.  I believe this may be true when it 
comes to the EDE project style that generates Makefiles.  While that is 
a nifty idea, it is hard to implement in a flexible and robust way.  As 
such, it is pretty good for simple projects, but is too aggressive an 
idea to claim as a general tool.  Folks who come at CEDET from the IDE 
mindset tend to start there and get disappointed.

There are many other tools in CEDET that many users do use and depend 
on.  There are 345 members on the cedet-devel mailing list.  Only 1 of 
them is me.  That seems like a pretty good user base.

> Maybe it's an occasion to make that point up:
>
> As for me, the maybe silly reason is EIEIO. Never understood what it's
> good for - and didn't want to learn something not understood...
> WRT what's reported from other OO-tools, was not surprised to experience
> slowness.
>
> The problem with OO-programming seems some hardly predictable
> multiplying of procedures.
> In addition EIEIO is written in Emacs Lisp, which isn't known to be very
> fast itself.
>
> So at some point got the idea CEDET will never be reliably fast...
>
> Sorry for that.
> Given that's true - what about dropping EIEIO and re-building everything
> in plain Emacs Lisp?

Before I wrote CEDET, I built a set of tools that did similar things and 
ran into some serious problems making it work.  I took a step back, and 
instead focused on infrastructure, such as a parser-generator instead of 
writing more parsers with regexp, and then an object system, instead of 
managing polymorphism by hand every time I called a function.  I don't 
think it is really possible to build something as flexible as CEDET 
without a CLOS like tool.

The key thing that EIEIO lets me do is define interfaces that allows 
modules to work together.  For example, there is a tag-table concept in 
the semantic system for managing lists of symbols found in the source 
code it parses.  The parser system all knows how to populate and 
maintain a table.  There is also code that searches tables so you can 
find a tag to jump to, for example.  By defining the core interface as a 
table class with EIEIO, I can also create other classes that manages tag 
tables from GNU Global, and just stick it in a list of other tables to 
search.  The code searching tables doesn't have to know  about GNU 
Global.  The Global person doesn't have to know about jumping to tags. 
And no-one has to write some weird bit of code that reaches into a plist 
to get a function symbol to call.  I was able to move the Java 
completion in CEDET from in-file only to surprisingly robust for Android 
in an afternoon just by writing a database that parses a few.jar files. 
 Nifty.

When I think of IDEs that are heavily OO, I tend to think that the UI is 
built that way, with more doo-dads to click on than you could possibly 
use.  There is no UI code (ie - widgets) in CEDET based on EIEIO.  In 
fact, I think COGRE is the most UI like thing I've built with EIEIO, 
mostly on a lark to see if it could be done.  It turned out ok.

As for performance, there was a time when EIEIO didn't compile.  That 
was pretty darn slow.  I've spent many hours in the profiler tuning it, 
and it is much better now, and EIEIO barely shows up when I profile 
high-level tools.

Does that help?
Eric