Re: Emacs contributions, C and Lisp

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Sat, 01 Mar 2014 20:03:45 +0100
> 
> > Your needs are not the only ones, and not necessarily representative
> > of those of others.
> 
> Making an strawman does not help to the discussion.

It's not a strawman at all.  Different users do have different needs
and preferences, there's nothing wrong about that.

> >> We don't need the backend, but we need all the other big parts. In the
> >> case of Clang, that's probably more than 70% of its source code (the
> >> backend is provided by LLVM, which is a segregated code base.)
> >
> > Because Clang was designed and implemented as a compiler, first and
> > foremost, and not as a CEDET backend.
> 
> You are showing your ignorance here.

I forgive you.

> You can go to clang.llvm.org and see by yourself, on the front page,
> that you are wrong, but I guess that you wont to.
> 
> >From day 1, Clang aimed at modularization, with each component providing
> a convenient API for the benefit of external clients.

If you ever managed a large software project (I did), then you know
that the main goal of any project will show in its design and
implementation loud and clear, no matter what secondary goals are
there.  A compiler whose main goal is to be a set of modules will
never be a good compiler.  In fact, no coherent software system can
ever be made successful if it "aims at modularization" as a primary
goal.

Because I think Clang is a good compiler, I'm sure when it serves as a
library, it pulls in gobs of code that isn't strictly necessary.  It
simply cannot be any other way.

> Just in passing I'll mention that that was one of the main motivations
> for creating Clang. Some of today's Clang heavy contributors would have
> preferred to do that modularization on GCC instead of starting from
> scratch on a new project, but that was forbidden. Hence Clang is, in
> great part, a consequence of the GNU policies intended to avoid GCC
> usage by non-free software. Ironic, uh?

You are again going into politics.  Sorry, not interested.

> But yeah, I'm the one who resorts to hand-waving and unsubstantiated
> claims.

We are talking about features Emacs needs to become a better IDE.  All
I said is that there's more than one way, and the one I think we
should explore first is CEDET.  I didn't say it will necessarily
provide the solution, all I said is that we should _try_.  It's really
the logical way any software shop behaves: first see if any existing
package could fit the bill, and only after that do something from
scratch, or buy an external product.  This must make sense to anyone
who is in this business for any significant time.

You, OTOH, claim from the get-go that this way will certainly fail,
and should be dismissed without even trying, and back that up by toy
programs and slogans.  So yeah, you are the one who makes
unsubstantiated claims.

> > These repetitions serve nothing else but discouraging people for
> > trying different approaches -- is this really your goal and your
> > agenda?
> 
> Eli, I sincerely hope that you are not being serious with this. I prefer
> to mentally see you right now having a good laugh at my stubborn attemps
> to educate you.

If you want me to laugh, add a smiley.

But my worries are first and foremost for the lurkers out there.  They
might not laugh even if you do add a smiley.  You don't attract
newcomers by telling them that the job is so hard they shouldn't even
try.

> Although my real intention is to kill your claim that going with CEDET's
> C++ parser makes Clang/GCC unnecesary.

If the CEDET based solution works well enough, Clang/GCC will indeed
be unnecessary.  They could be useful alternatives, though.

> Hopefully other members on this community got the idea that what you
> propose is not such a great idea.

If they have eyes in their heads, they will see that I'm right, I
hope.