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 14:54:22 +0100 Message-ID: <87egvaxshd.fsf@newcastle.ac.uk> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410962091 25234 80.91.229.3 (17 Sep 2014 13:54:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 13:54:51 +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 15:54: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 1XUFgx-00077A-Mz for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 15:54:43 +0200 Original-Received: from localhost ([::1]:45196 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUFgx-0005Wa-DP for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 09:54:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUFgp-0005WD-Us for emacs-devel@gnu.org; Wed, 17 Sep 2014 09:54:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUFgi-00061S-7F for emacs-devel@gnu.org; Wed, 17 Sep 2014 09:54:35 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:50889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUFgi-00060k-19 for emacs-devel@gnu.org; Wed, 17 Sep 2014 09:54:28 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1XUFge-0001RK-A8; Wed, 17 Sep 2014 14:54:24 +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 1XUFgd-0007mG-1O; Wed, 17 Sep 2014 14:54:23 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 17 Sep 2014 08:50:45 -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.12 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:174425 Archived-At: Stefan Monnier writes: >> 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. > > I think this reflects 2 things: > - machines still did get faster over the last 10 years (much less so > than over the preceding 10 years, but also probably much more so than > over the next 10 years). Well, Emacs is a text editor. The CPU demands of the task haven't increased that much over the last 10 years either. > - you've internalized Elisp performance sufficiently that you > self-censor yourself such that you don't bump into it. Have you looked at any of my code recently? Still, yes, you may have a point. > >> 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. > > That's part of the idea, yes. > >> 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. > > I'm far from convinced. It may seem that way if you don't think too > hard about what it would look like, but once you realize that your JS > hacker will have to learn how to manipulate Elisp lists, Elisp vectors, > Elisp symbols, how to access Elisp functions and Elisp variables ... > > That JS code won't look very much like your typical JS code. It will be > so baroque that they will "have to learn it". And they may even hate it > more (because it surely will look ugly). > > Interoperability between languages is *hard*. Doing it so the result is > lightweight and elegant (and moderately efficient) is rarely possible. Yes, you are absolutely right. I am using Clojure for its Java interop at the moment, and it has been done well. Replicating that would be no mean feat. Phil