Re: Emacs contributions, C and Lisp

["Perry E. Metzger" <perry@piermont.com>]

On Wed, 07 Jan 2015 21:46:14 -0500 Richard Stallman <rms@gnu.org>
wrote:
> Are you thinking of this only in terms of the amount of work?
> I'm concerned with avoiding dangers.

Here is a real danger: people are ignoring free software as a way to
get their work done because non-free software provides them with
capabilities that free software does not. The danger is even worse
because the people using non-free software to do their work in this
instance are programmers, who are learning that if you want to be
productive, you use software like XCode, and not software like Emacs.
In the longer term, this could very well reduce the pool of
developers who are part of the free software ecosystem.

Equally bad from your point of view, and unrelated to editors, I'll
personally testify that the academic programming languages community
is pouring all its effort into LLVM from every side, and this is
because LLVM can be used in a modular manner without someone having
figured out in advance what sort of work someone might have wanted to
do.

I can think of a half dozen projects at the University of
Pennsylvania (my university), VeLLVM, Ironclad C++, and my own work
on C safety being just three, where no one used GCC as a platform
specifically because of the more open architecture in LLVM. You
can find literally dozens of projects done at other universities,
such as John Regehr's work on integer overflow detection in C and
C++, where LLVM was the only platform considered for the work because
it is considered impossible to use GCC in a modular fashion.

A whole generation of compiler experts is being trained to use LLVM
and only LLVM for this sort of work, where 15 years ago they would
have used GCC.

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.

> 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.

We do understand that the choice may not be perfectly "safe" in the
sense you mean. People may very well do what you suggest and build
non-free compiler components on top of free compilers, just as they
run proprietary software on top of GNU/Linux.

However, allowing people run some proprietary software on top of
GNU/Linux has driven literally every other Unix-like operating system
into the ground while slowly eroding the proprietary software
itself. Sure, Oracle runs on GNU/Linux, but almost every database
system out there is a free database, not something like Oracle.

The LGPL gives up a powerful tool in exchange for an important result.
It is true that the Gnu C library could have prevented itself
from being linked in to proprietary software, and this is nearly the
same situation as you face with GCC, but this would have been
counterproductive, causing proprietary software users to avoid
GNU/Linux entirely. Instead, they got absorbed into the ecosystem and
ultimately it was the proprietary software that was heavily damaged,
not FSF's goals.

GCC is often used to compile proprietary software, but allowing GCC to
be used that way also meant that the closed source compiler platforms
were heavily damaged.

The current situation is one in which there are lots of proprietary
IDEs that use hooks onto compilers, some into proprietary ones and
some into LLVM, to let people do all sorts of very useful things. It
is also a situation where loads of people want to do hacks on top of
compiler infrastructure and have found that LLVM is the only easy way
to do that. Yes, there is a trade-off here, but we think it is
important enough to permit, because for practical purposes the result
of not allowing the usage will be to push people further in a
direction we do not want.

> You can't do this by brushing off the issue.  That will only
> convince me that you haven't seen the issue.

I think most of us understand the issue as you see it. I think the
distinction is that most of us believe the trade-off is important. Yes,
this may indeed mean that some proprietary software ends up being
based on GCC just as some proprietary software is based on GNU/Linux,
but the overall impact will be positive, and the risk is much lower
than the reward.

Perry
-- 
Perry E. Metzger		perry@piermont.com