Re: Contributing LLVM.org patches to gud.el

["Stephen J. Turnbull" <stephen@xemacs.org>]

 > Eli Zaretskii <eliz@gnu.org> writes:

 > > When LLDB gets anywhere near GDB in functionality and usability,
 > > let alone surpasses it, maybe then I might get interested.

Your personal preference for GNU software is well-known.  But your
preference doesn't help explain, let alone fight, the increasing
popularity of LLVM that Richard perceives as a potential threat to
software freedom, AIUI because of the legal and technical ease with
which portions of LLVM could be replaced with proprietary software.

BTW, in my usage, the only thing that lldb lacks that gdb has is my
muscle memory (lldb's command set is much more regular, but therefore
*different* and I haven't memorized it yet, partly because muscle-
memory-compatible aliases are provided for the most common commands
like "run", "backtrace", and "break").  I'm not a "power debugger" in
C, so it doesn't surprise me that you find lldb less satisfactory.
But this difference indicates you should be careful to worry about the
"innovator's dilemma", where an inferior product is "cheaper" (in some
sense) and takes over the non-power-user market, and in that way gains
the resources needed to improve rapidly and decisively.

David Kastrup writes:

 > Seems you missed where people stated that its willingness to talk
 > about values that can only be deduced by cooperation with the
 > compiler was making a crucial difference in usability over gdb.

That's not really fair, David, for the same reasons.  I was reporting
personal experience and personal preference.  Note that on Mac
"Yosemite" the default compiler is clang, and gdb may not yet be so
clued in to clang's idioms in DWARF or whatever debugging it emits, by
comparison to its understanding of GCC.  In other words, it's somewhat
unfair to compare clang + gdb to clang + lldb[1], and I suspect that
Richard may consider that "unfairness" to be a mitigating factor,
because lldb would not be likely to infect the GNU world so quickly.

 > At any rate, you seem to be _totally_ on the other side of Richard on
 > this one.  You want to start thinking about LLDB when it is getting more
 > useful than GDB, he wants to stop people from thinking about LLDB when
 > it is getting more useful than GDB.

Touche!  But they're really saying the same thing in different ways.

Eli, again:

 > > For now, it's a niche debugger, not unlike dbx.

Hardly.  True, from one point of view Mac OS X itself is a niche OS.
But from the same point of view, Emacs itself is a niche app.

 > > Why should we care so much if LLDB support will land today, next
 > > week, or next year?  We shouldn't burn so much energy on even
 > > discussing it.

Perhaps not discussing the philosophy on this list.  But there are a
*lot* of people using Emacs who are also using clang (essentially all
Mac developers who use Emacs, for example).  LLVM support is important
to some of us, and it *is* *free* software.  My take is that Stefan is
correct: Just Do It.  Among other things, somebody (David?) said
something like "this kind of decision needs to be made many times by
many maintainers, the rule needs to be clear and simple."  Support for
free software that Emacs users are already committed to should not be
a problem, while Emacs functionality that advertises superior
capabilities of non-GNU software should be avoided.[2]

IMHO, Richard should spend his energy on the hard, important problems,
like whether gcc and gdb need a good ass-kicking to address these
usability issues (from what you write, the issue may not exist for
that combination), or whether gdb should try to compete with lldb even
when the compiler isn't gcc.

 > Well, GNU does not turn on a dime.  So there is nothing wrong with
 > thinking ahead.

It's absolute essential, actually, since Richard's preference is for
core GNU tools to be monolithic so their main functionalities cannot
be easily replaced (or in some cases even accessed) without large
investment.  That, while most competing projects have made agility of
development a core value.

 > >> > Free Software is about freedom of developers as well.
 > >> 
 > >> Not at its core.
 > >
 > > Yes, at its core: the freedom to change the code requires a developer
 > > who can actually do that.
 > 
 > <URL:http://www.gnu.org/gnu/manifesto.html>
 > 
 > You'll find that wherever conflicts of interest between users and
 > programmers are considered, Richard puts the users' interests first.

Gag me!  I find it very sad that free software advocates are making a
distinction between users and developers.


Footnotes: 
[1]  Nor have I compared gcc + gdb to gcc + lldb!

[2]  I think the "deliberate attack" possibility is a red herring.
And I disagree with Richard and Stefan on another issue: as much as I
think the *existence* and *availability* of Excorporate is a good
thing, I think it would be a strategically good idea to remind its
users that GNU is not here to support them in that usage.  I don't see
any advantage to free software in having Emacs distribute it, even as
part of ELPA.  I somehow doubt that the availability of Excorporate
will cause any Outlook users to switch to Gnus, although it might
catch some Thunderbird users.  OTOH, users of gud.el will be able to
switch from lldb to gdb more easily, and I find that more plausible
(especially on a case-by-case basis).