From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 17 Sep 2014 12:17:21 +0100 Message-ID: <87sijqxzr2.fsf@newcastle.ac.uk> References: <87wq97i78i.fsf@earlgrey.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410952683 30455 80.91.229.3 (17 Sep 2014 11:18:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 11:18:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 13:17:56 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 1XUDFD-00032k-NX for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 13:17:55 +0200 Original-Received: from localhost ([::1]:44119 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUDFC-0003zs-SY for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 07:17:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUDEv-0003zX-5r for emacs-devel@gnu.org; Wed, 17 Sep 2014 07:17:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUDEo-0004tO-IH for emacs-devel@gnu.org; Wed, 17 Sep 2014 07:17:37 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:43405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUDEo-0004s6-C4 for emacs-devel@gnu.org; Wed, 17 Sep 2014 07:17:30 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1XUDEf-0000FJ-Ff; Wed, 17 Sep 2014 12:17:21 +0100 Original-Received: from jangai.ncl.ac.uk ([10.66.67.223] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XUDEf-00042n-HR; Wed, 17 Sep 2014 12:17:21 +0100 In-Reply-To: (Stefan Monnier's message of "Tue, 16 Sep 2014 11:50:54 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.22 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:174410 Archived-At: Stefan Monnier writes: > First, of course we can keep on evolving Elisp on its own. This has > worked OK for the last 30 years, so it's not such a terrible choice. > The main problems I see with that: > - Elisp is slow and as CPUs aren't getting faster, its slowness makes itself > noticed more often. I've been going through some 10 year old elisp of mine recently. The thing that surprises me is how many times I mention performance in it. I rarely worry about this these days. Elisp performance as is seems rarely an issue. Where I would say that there is an issue is that too much of Emacs is written in C. Having a faster elisp would allow moving more into lisp and thus having more of Emacs extensible dynamically. > - Lack of some features, most notably FFI and concurrency. > - Lack of manpower. I'd add a fourth. People who want to extend Emacs for their own purposes have to learn it. Having JS extensibility would be an enourmous win. > So if we go for Guile-Emacs, we'll be stuck with Guile, i.e. we'd > have (old and new) packages that use Elisp, new packages that use > Scheme, maybe yet other new packages that use, say, Javascript (or some > other language support by Guile). That would make the work of Emacs > (and GNU ELPA) maintenance harder. Thinking of Emacs as an entire ecosystem, most of Emacs is already maintained independently from either Emacs core or GNU ELPA. For common languages (like Javascript), the maintaince might be ligtened because more people would be available. Of course, it is worth mentioning that some of the big advantages from a language like Javascript come from the implementation. A guile based implementation wouldn't benefit from the intensive JS VM development that has happend over the years. Phil