Re: Emacs contributions, C and Lisp

[Stephen J. Turnbull]

David Kastrup writes:
 > "Stephen J. Turnbull" <address@hidden> writes:
 >> David Kastrup writes:
 >>> "Stephen J. Turnbull" <address@hidden> writes:
 >>>> David Kastrup writes:

 >>>>> It only weakens the GPL

[big snip and back to David]

 > The GPL can _always_ be enforced by the copyright holder.
 > Collecting the assignments makes sure that the FSF has the full
 > ability to enforce

You could have stopped there.  *You* said "weaken the GPL" when what
you really meant was "weaken the FSF."  OK, conceded.

But you continue:

 >> If the GPL can't be enforced,
 > 
 > The GPL can be enforced.

In theory, yes, each of a large collection of copyright-holders can
enforce the GPL on their little bit.  In practice, as you say:

 > That's underwhelming.

That is, such a collective's threat of action to enforce is not
credible, and the costs of defending in the unlikely event that such
challenge arises becomes an ordinary business risk.

Aside: I wonder if perhaps you could defend something like XEmacs or
the Linux kernel or Python with a class action suit.  I'll have to ask
a lawyer.  RMS might want to ask his, too, since the FSF owns enough
of XEmacs, and probably other non-GNU software, to be a plausible
class representative for them.  Or maybe he already has. :-)

And then your main point:

 > It doesn't weaken the GPL.  It weakens GCC, and with it, the GNU
 > project.  Part of the strength of the GNU project lies with GCC
 > setting language and performance standards,

Except that last is now an exaggeration.  Obviously GCC no longer sets
performance standards, and since the reason I switched my default to
Clang was to get better error messages, in at least one aspect it
seems to be lagging on language standard-setting.  (But see discussion
below, especially fn. 1.)

This is what happens when you have no real competition.

 > and it's bad if the most thorough modes we make available with
 > Emacs are not able to support the GCC dialects.

Now that, as Richard would say, is a misrepresentation.  Of course
nothing prevents Emacs from supporting GCC dialects, certainly not a
fiat from Mt. Olympus.  Of course Emacs *should* support them.  And if
such support was lacking or weak, I think there's some chance that
Richard would come around and encourage development of that mode.
Don't you?

AFAICS, the issue at hand is supporting unique features of free
software whose licenses do not defend freedom according to Richard.
There are a lot of such licenses, including those used by TeX, Perl,
Python, Ruby, ncurses, X11, and Apache.  Why doesn't the logic that
applies to LLVM apply to them too?

 > So in this case GCC and the GNU project were in the situation of
 > creating a de facto standard.  Once Emacs supports what Clang
 > provides rather than what GCC provides, not even Emacs will support
 > any new features of GCC.

Hm.  You've said that twice, now.  This is a leap that I cannot
follow.  Would you explain?  I understand the rest of your argument
that *compiler users* could abandon GCC en masse.  What I don't see is
why that would prevent Emacs from supporting unique GCC features any
more than it prevents Emacs from supporting a zillion true niche
applications (eg, modes for .Xresource and RGB.txt manipulation).

Furthermore, my personal estimate is that GCC's capacity for relevant
innovation has been sapped by its dominant position and by the focus
on internal issues that comes with high-stakes standard-setting.  And
furthermore, refactoring to make internal data structures available to
cooperating applications has been forbidden for a decade or so.  Just
where are those "unsupportable" new features going to come from?  And
what is going to make them radical enough from the users' (and Emacs's)
point of view that support is non-trivial?

 > GCC plays a central role in where people place their focus, their
 > loyalties, and their goals.

Not in my experience.  I tried Clang *once* because an XEmacs user
posted about warnings it was issuing, discovered that its error
messages and warnings were way more useful than GCC's, and switched
immediately.[1]  Perhaps kernel developers and a few others pushing the
envelope of C performance or C++ conformance experience GCC as central,
but for most of us it's just a tool, quite replaceable, I suspect.
glibc and Emacs are far more iconic, and of course glibc is universal
to the GNU System.

 > It's one of the actually active ties to the GNU project that the
 > Linux kernel has.

That's because the kernel developers have not been supported by GNU.
As usual with GNU, it was "my way or the highway."  Linus took the
highway, and almost all kernel developers went with him.  There had
to be a better way to handle that.  There has to be a better way to
handle LLVM.  I'm not saying "mistakes were made"[2], but surely the
result was undesirable.  And I'm saying "we really don't want a
central component of the system developed outside of the 'House of
GNU' again."[3]

 > So we want to have GCC stay technically competitive

No, at least based on current behavior, you don't want *GCC* to *do*
anything.  You want *LLVM* to *fail to innovate* in the same way that
GCC is *prohibited* from innovating.  The effect is the same, but your
statement suggests that GCC is being defended, when in actual fact
what is happening here is that Emacs is being commanded to attack LLVM
(in the sense of "trade war", ie, withdraw cooperation from an external
entity whose competence threatens a protected local industry).

This is only to the detriment of Emacs and LLVM users.  It does not
hinder LLVM's attempt to achieve compiler dominance, and may even
en(cou)rage some because they see it as mere spitefulness from GNU,
and evidence that GCC really is lagging, even as viewed by GNU itself.

 > in order to retain a non-licensing based connection into those kind
 > of projects and, not least of all, the Linux kernel.  On the other
 > hand, staying technically competitive is not self-serving but it
 > serves to have a wider audience for our non-technical goals.
 > Giving up the latter in order to have a stronger stand for the
 > former is sort of pointless.  Sort of what one calls a "dying
 > throw" or "parting shot".

That justifies redoubling efforts to innovate in GCC, while respecting
the self-imposed limitation on acceptable areas for innovation.  It
doesn't justify "trade war".

 > When put to the choice, we'd rather give up on Android than GNU.
 > And us having to take that choice at some point of time is what
 > Clang/LLVM are working towards.

I rather think you overstate the importance of GNU in the thinking of
LLVM developers.

 > Once Clang/LLVM become the compiler for Android, it is a matter of
 > time and hipness before it becomes the default compiler for the
 > Linux kernel.
 > 
 > Once the kernel is bootstrapped using Clang/LLVM, it is a matter of
 > time before the userland of big distributions is compiled using
 > Clang/LLVM as well, with GCC becoming optional.
 >
 > At some point of time, it will become harder to compile the Linux
 > kernel with GCC out of the box, and bootstrapping a full GNU system
 > will mean that we need to revert to the HURD, mostly relying on
 > using Linux drivers.

A sad future history indeed.  And you think that refusal to integrate
Emacs modes that use Clang to improve the Emacs user experience is the
finger in the dike that will save Holland, er, the GNU Project?

The obvious fact is that GNU can't stop the process you've described
-- it all happens outside of GNU!  You can only hope it will fall
apart due to its own internal inconsistencies.  Unfortunately, the
process you describe is pretty clearly the GNU Project falling apart
due to its own internal inconsistency.  Specifically, it wants to be
universal but denies the clearly expressed aspirations and preferences
of the rest of the free-software-producing world and their users.

And now, it's denying the aspirations of some of its own members,
merely to spite those with different beliefs about defending freedom.

GNU's beliefs are essential to the free software movement.  Nobody can
deny that.  But this decision is mere spite, without real effect, and 

 > At least until someone sues us for combining GPLv2 drivers with a
 > GPLv3+ kernel.

Surely GNU will not take that risk.  If that ever happens, RMS and the
GNU Project lose so much face that it's "game over".  If the HURD is
already doing so, isn't it time for a revolution?  (Preferably led by
RMS himself.)

 > And if you are saying "that's too pessimistic.  All of this _could_
 > happen, but that's by no means sure."

No.  I'm saying you're way too *optimistic*.  The story you tell is
way too plausible to be ignored, and the current response is way too
weak.  GNU outlived Zawinski's challenge, compromised with Drepper,
and surmounted the EGCS challenge, but this time could easily be
different (I'd put a small wager on no effective response and GCC
gradually falling into disuse except for building HURD-based systems).

What's different now?  *Big* business has learned to cooperate
effectively with free software projects, both idiosyncratically (eg,
the Linux kernel) and systematically (via organizations like the
Apache Foundation).

Looking around more widely, the GNU Project is doing nothing effective
to catch up to commerce-friendly free software leaders[4], and
resorting to shooting spitballs at front runners (Linux and LLVM) and
coddling con men ("GNU" Bazaar, whose members, with the presumed
exception of the Invisible Maintainer, have far less allegiance to GNU
ideals than I do).

It's funny.  I could happily live in the GNU System as described in
the Manifesto, plus the Linux kernel.  I could get all of my current
work (with the exception of web publication and reading HTML mail and
*Office docs -- even submission of *Office docs can usually be avoided
by using plain text or PDF and w3.el is sufficient for the browsing I
*need* to do -- including both $DAYJOB and FS support and development)
done with today's versions of the base system, applications, and
libraries listed there.  But I look out at the world, and I see that
others want a lot more.  Some of it (eg, web browsing and publication,
mailing lists, and issue tracking) is convenient for my activities --
but with the exception of GNU Mailman, *none* of that additional
convenience can be achieved with GNU projects.

Somebody needs to figure out whether that last sentence is too true in
general to be ignored.  (Eg, my desktop is XEmacs, so I don't include
GNOME -- surely a convenience to many -- in my list of "conveniences".)
And if so, why it happened and what to do about it.

Hey, GNU!  WTF?!

 > the whole point of being behind GCC is to do what is in our power
 > to push against this happening.  Our power may be small compared to
 > those of the universe, but that has not kept us from making a
 > difference by applying it aimedly and timely enough.

Being behind GCC?  What have you contributed to GCC lately?  Besides
apologia for shooting spitballs at Clang, that is.  If you wanted to
*effectively* support, GCC you'd be ignoring me and posting ideas and
encouragement and maybe even patches on GCC lists instead, no?

The whole thing reminds me of my host country.  "Alas, alack, a 'Lost
Decade' for the Japanese economy.  We must reform!"  Oops, we can now
make that two decades -- and counting, "Abe-nomics" not withstanding
(Band-Aids #1 and #2 have been applied, but the painful surgery has
not been done, and pretty clearly the administration intends to avoid
it).  And now they're shooting spitballs at TPP and justifying "attack
as the best defense" military strategy.

I don't know what to do about either Japan or GNU.  I've presented my
ideas, but (in both cases) they run counter to the natural instincts
and/or principles of the leadership.


Footnotes: 
[1]  The effect may be temporary, of course: since the architecture is
different, the errors and warnings issued are likely to be different.
Long experience with GCC means those are *gone* (I mean, 100%) for
older versions of GCC.  Clang may just be reporting on issues that it
catches that have been present for a decade.  I'll have to go back
and see which does a better job once we're "Clang clean".  However, I
bet that Clang's architecture gives it a lasting advantage here.

[2]  Perhaps the approach taken to trying to cooperate with Linus et
cie. was the best possible, especially given the important differences
on licensing.  I grant those weren't reconcilable by concessions from
the GNU side.

[3]  Well, to be honest I don't care specifically about the compiler.
I do think that a strong GNU (= free software movement) is important,
maybe essential, to a healthy FLOSS community.  I don't think it has
to be *dominant and universal*, though.  Bottom line: if GNU thinks
"owning" compiler space is important to its goals, I'm happy to assume
that's important in my discussion.

[4]  The GNU Project has no entrants in kernels (HURD? give me a
break), scripting languages (Guile? ditto), web servers, or web
frameworks, the areas that scare Microsoft and power Google.  It's
most innovative on the desktop (GNOME), but still way behind the
industry leaders (Microsoft in installations and Apple for overall
design) and facing intense competition even for GNU System desktops
(KDE).  It doesn't have a distribution to speak of, not even a package
manager.  And now its long dominance in system software toolchains
(GCC et cie.) is seriously challenged.