[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: David Kastrup
Subject: Re: Emacs contributions, C and Lisp
Date: Thu, 08 Jan 2015 16:03:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

"Perry E. Metzger" <address@hidden> writes:

> The long term result of all of this may very well be to do exactly the
> opposite of what you want -- to convince compiler researchers that
> LLVM is the only serious platform for their work, and even worse, to
> convince developers in general that free software is too hard to use
> and that non-free software is the way for them to get their work done.

LLVM is not non-free software.  It is non-copyleft software.  The
compiler researchers you are talking about are using free software, but
their work is ultimately also enabling non-free software that can no
longer be used in open research.

For the academics, we are not talking about the difficulties of using
free software vs non-free software but rather about using (and
consequently also producing) copylefted software vs non-copylefted
software: actual non-free software is hard to work with and write about

Academia of course is also set up to serve industries with "standard"
production, marketing, and licensing models.

>> If you want to convince me generating the whole AST is safe, you have
>> to understand my concern and take it seriously.
> We do indeed understand I think, and take it seriously. The issue is a
> real one. I think the distinction is the rest of us see the tradeoff
> differently than you do.

Most of the "if only $x, then magically $y" scenarios don't really work
as thoroughly as people imagine and end up a tempest in a teapot.
I suspect that there would be a lot more catching up to do apart from
unencumbering module/data interfaces into GCC.

However, we _do_ apparently have people chomping at the bit to improve
the integration of GCC into Emacs as a programming editor which have
serious problems getting a workable roadmap agreed on, and the mere
necessity for getting everything agreed upon in advance is a real
detriment: most work requires exploring a number of technical dead ends
before finding a productive path, and when each of those dead ends
requires a big upfront fight, the perceived cost in disappointment and
lost efforts is much higher.

We are losing contact with academia, that's true.  I don't see a
short-term fix for that.  But we are losing also contact with willing
hackers who'd actually want to work on Emacs/GCC integration and who'd
be perfectly willing to just leave the legal considerations in the hand
of the FSF but who are barred from working on the implementation.

And that's really worrying.  I think there's too much baby in the
bathwater we are throwing out here.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]