From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Tue, 04 Mar 2014 15:56:11 +0900 Message-ID: <8761nusb90.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83bnxuzyl4.fsf@gnu.org> <871tyqes5q.fsf@wanadoo.es> <87a9ddg7o8.fsf@engster.org> <87d2i9ee8t.fsf@engster.org> <874n3ke1qn.fsf@engster.org> <87sir336qn.fsf@fencepost.gnu.org> <20140301215057.GA19461@thyrsus.com> <87fvn1y0vx.fsf@fencepost.gnu.org> <87fvn0senq.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1393916195 32430 80.91.229.3 (4 Mar 2014 06:56:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Mar 2014 06:56:35 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 04 07:56:44 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WKjHN-0005OO-Bd for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 07:56:41 +0100 Original-Received: from localhost ([::1]:43433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKjHM-0002L5-RP for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 01:56:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKjHD-0002IT-3l for emacs-devel@gnu.org; Tue, 04 Mar 2014 01:56:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKjH5-0007hJ-Iy for emacs-devel@gnu.org; Tue, 04 Mar 2014 01:56:30 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:41374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKjGx-0007gM-5e; Tue, 04 Mar 2014 01:56:15 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 07F37970902; Tue, 4 Mar 2014 15:56:12 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E9D4C1A28E5; Tue, 4 Mar 2014 15:56:11 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:170123 Archived-At: Richard Stallman writes: > Reciprocity is an aspect of the point of the GNU GPL, but its main > point is _defending users' freedom_. Conceded. > With the GNU GPL (and copyleft in general), we make sure that all > copies of all versions of our code _respect users' freedom_. That's a nice euphemism for *dis*respect for the users. You treat them like children, fearing they will abuse their freedom by choosing bondage to proprietary software rather than choosing less capable free software, or even just saying no to the unique benefits of some proprietary software. The contrast with your support for removal of all restraint on various other kinds of dangerous freedoms (where the most at risk are real children rather than possibly childish adults) is striking. > stifling friendly competition is a very bad thing, > > By calling LLVM "friendly competition" you misrepresent the issue at > stake. You're wasting your time, asking me to change my mind based on > ignoring what's at stake. I apologize for using the word "friendly"; I should remember that your sense of humor doesn't extend that far. But I am not misrepresenting what's at stake any more than you are -- I'm simply presenting a side you wish we could ignore. > In any case, we are not in a position to stifle LLVM, so you're > discussing an imaginary issue. Then what the heck are you trying to do? The results are increasing enmity with the LLVM developers and unhappiness among Emacs developers. There are no practical benefits of this policy. The claim that a really minor potential attraction of Clang/LLVM will be erased is surely false. Eclipse and vim, among others, will take advantage of it. So at that point, what you have succeeded in doing is reducing the attractiveness of Emacs, too. And that's the end of the "benefits". I see no good to come of this. It's unfortunate that GCC is prohibited from emulating this particular feature of LLVM, but hey, why not just suck it up, man? That's *your* *arbitrary* prohibition, for reasons that apply specifically to GCC, not to Emacs. So be arbitrary again, and let Emacs implement completion based on features provided by free software (that happens to compete with GCC, but this feature could benefit GCC users, too!) Or let somebody else implement the feature, and Emacs collect papers and distribute it. > have we learned nothing from the Great Planning Experiments of > Marx-Lenin-Stalin-ism? > > Lots of projects make plans and implement them. If you equate making > plans to Communist dictatorship, you've gone off the deep end. And > that's not to mention that your accusation is so nasty that we > shouldn't be on speaking terms. For heaven's sake, Richard, remember I'm an economist and consider history. I *did* not mean the "dictatorships of the proletariat". Note that those dictatorships have mutated (sometimes non-Communist, sometimes unreconstructed) but survived. I *did* mean the "great planning experiments" which did stifle competition. OK, you're not in a position to stifle LLVM, but you certainly wish it didn't exist, don't you? You wish that all that effort would flow into GCC, don't you? But (like the Communist planning organs) GCC is a highly political community, because the stakes are so great. GNU has played its part in that politicization (by delaying implementation of plug-ins and exportation of useful internal data structures for example), but the fact that GCC is both an important input and partly shaped by the ISO standardization process is even more important in its politicization. Now, the "great experiments" did channel the entire efforts of (national) communities into allegedly rational plans, and *look what happened to those communities*. "Post hoc ergo propter hoc," I know, but even a fallacy can give true results sometimes. GCC's decade of dominance, attracting many of the best and brightest compiler writers, may have done the same thing to it. And (as I pointed out to David elsewhere), though GNU has surmounted challenges from XEmacs, separatists in glibc, and EGCS, LLVM may very well be different because *big* business and projects producing free software have learned to cooperate well. LLVM is by far a stronger challenge to GNU than anything it has experienced except the Linux kernel itself. If LLVM does achieve the kind of dominance that GCC has enjoyed for the past several years, and (as David fears) it becomes the compiler of choice for GNU/Linux distros (not to mention Android/iOS/OSX), then what? Perhaps at that point you'll look at the situation and decide GNU needs a competitive compiler suite, and allow plug-ins and export of internal data structures to compete with (even conform to!) LLVM APIs. Perhaps you can deny the very *possibility* of such a future. But if not, why not *consider* using "license judo" on LLVM? The idea is to preempt that future by (1) allowing Emacs to support Clang/LLVM features if that suits the Emacs contributors, (2) removing the absolute block on "export" and the implied refactoring into multiple executables (and adding a "free software compatible" API as you recommended for the kernel modules and GCC plugins, if that is feasible), (3) encourage the GCC community to adopt Clang/LLVM architecture, API, and implementations, and (4) watch designs, implementations, and eventually contributors flow *out* of LLVM and *into* GCC because of the licenses. In the end, one of two things is likely to happen: LLVM withers, or LLVM adopts the GPL in order to stem the one-way flow of innovations. Either way GNU (if not GCC) wins. Note that I do not claim that there is *no* innovation in recent GCC; merely that it's (a) slower than it might otherwise be because the incentive of strong competition has been lacking and specifically slower than in the newly arisen competition, and (b) less effective than it might be because the absence of competitors (not to mention administrative restriction on kinds of innovation) means that bold experiments are far fewer. The strategy above of course depends on there being plenty of innovation in GCC still -- thus by efficiently copying Clang/LLVM it can catch up where it needs to, and innovation unique to GCC will then attract both commercial support and volunteer developers. Caveat: I don't claim there's no risk to that strategy, nor that it conforms to your principles (though I think it might). I do insist that there is an equally big risk to your strategy, minor annoyances along the way, and I wonder whether it's worth adhering slavishly to principle only to see that principle end up in the dustbin of history.