From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Wed, 17 Sep 2014 08:50:45 -0400 Message-ID: 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 1410958281 4696 80.91.229.3 (17 Sep 2014 12:51:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 12:51:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: phillip.lord@newcastle.ac.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 14:51:14 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 1XUEhS-0001Gk-8o for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 14:51:10 +0200 Original-Received: from localhost ([::1]:44892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUEhR-0007hT-OV for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 08:51:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUEhH-0007ak-SO for emacs-devel@gnu.org; Wed, 17 Sep 2014 08:51:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUEhA-0005U7-6d for emacs-devel@gnu.org; Wed, 17 Sep 2014 08:50:59 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:19547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUEhA-0005TZ-31 for emacs-devel@gnu.org; Wed, 17 Sep 2014 08:50:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZDoJ4g0rAPYEXF3SCJQEBAQECAVYjBQsLNBIUGA1Vh1MI0hkXjnoHhDgEqRmBaoJwXCE X-IPAS-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZDoJ4g0rAPYEXF3SCJQEBAQECAVYjBQsLNBIUGA1Vh1MI0hkXjnoHhDgEqRmBaoJwXCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="90081525" Original-Received: from 69-165-145-6.dsl.teksavvy.com (HELO pastel.home) ([69.165.145.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Sep 2014 08:50:45 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 433CC62FAE; Wed, 17 Sep 2014 08:50:45 -0400 (EDT) In-Reply-To: <87sijqxzr2.fsf@newcastle.ac.uk> (Phillip Lord's message of "Wed, 17 Sep 2014 12:17:21 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:174417 Archived-At: > 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). - you've internalized Elisp performance sufficiently that you self-censor yourself such that you don't bump into it. > 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. Stefan