From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Thu, 8 Jan 2015 08:32:11 -0500 Message-ID: <20150108083211.5a85a077@jabberwock.cb.piermont.com> References: <83bnxuzyl4.fsf@gnu.org> <87fvn0senq.fsf@uwakimon.sk.tsukuba.ac.jp> <8761nusb90.fsf@uwakimon.sk.tsukuba.ac.jp> <87vbkovhh7.fsf@engster.org> <87387rvobr.fsf@engster.org> <83ppat84hk.fsf@gnu.org> <20150106143933.0090bc83@jabberwock.cb.piermont.com> <83r3v77ij6.fsf@gnu.org> <20150106154539.3d0752c4@jabberwock.cb.piermont.com> <87wq4ype3z.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1420724092 9413 80.91.229.3 (8 Jan 2015 13:34:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Jan 2015 13:34:52 +0000 (UTC) Cc: eliz@gnu.org, David Kastrup , monnier@iro.umontreal.ca, deng@randomsample.de, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 08 14:34:47 2015 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 1Y9DCQ-0005PL-Oe for ged-emacs-devel@m.gmane.org; Thu, 08 Jan 2015 14:32:31 +0100 Original-Received: from localhost ([::1]:46060 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9DCQ-0006Vk-8D for ged-emacs-devel@m.gmane.org; Thu, 08 Jan 2015 08:32:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9DCC-0006Vd-6b for emacs-devel@gnu.org; Thu, 08 Jan 2015 08:32:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9DCA-0001cb-Us for emacs-devel@gnu.org; Thu, 08 Jan 2015 08:32:16 -0500 Original-Received: from hacklheber.piermont.com ([2001:470:30:84:e276:63ff:fe62:3400]:42377) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9DC9-0001c3-6H; Thu, 08 Jan 2015 08:32:13 -0500 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 7265A14D1; Thu, 8 Jan 2015 08:32:12 -0500 (EST) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 1BC8A2DE9DF; Thu, 8 Jan 2015 08:32:12 -0500 (EST) In-Reply-To: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-apple-darwin14.0.0) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 2001:470:30:84:e276:63ff:fe62:3400 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:181057 Archived-At: On Wed, 07 Jan 2015 21:46:14 -0500 Richard Stallman 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