From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future (was: Guile emacs thread (again)) Date: Wed, 17 Sep 2014 20:24:18 +0200 Message-ID: <20140917202418.240bbd2c@forcix> References: <87wq97i78i.fsf@earlgrey.lan> 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 1410978322 26790 80.91.229.3 (17 Sep 2014 18:25:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2014 18:25:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 17 20:25:15 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 1XUJul-0001z6-5C for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 20:25:15 +0200 Original-Received: from localhost ([::1]:46712 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUJuk-0004rF-Me for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 14:25:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUJuc-0004oB-90 for emacs-devel@gnu.org; Wed, 17 Sep 2014 14:25:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUJuT-0006vZ-M3 for emacs-devel@gnu.org; Wed, 17 Sep 2014 14:25:06 -0400 Original-Received: from loki.jorgenschaefer.de ([87.230.15.51]:44169) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUJuT-0006ux-Ch for emacs-devel@gnu.org; Wed, 17 Sep 2014 14:24:57 -0400 Original-Received: by loki.jorgenschaefer.de (Postfix, from userid 998) id 2D14B201E0E; Wed, 17 Sep 2014 20:24:20 +0200 (CEST) Original-Received: from forcix (port-90824.pppoe.wtnet.de [84.46.67.60]) by loki.jorgenschaefer.de (Postfix) with ESMTPSA id 81D58201E0C for ; Wed, 17 Sep 2014 20:24:19 +0200 (CEST) In-Reply-To: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; i586-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.230.15.51 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:174454 Archived-At: On Tue, 16 Sep 2014 18:03:17 +0200 Lennart Borgman wrote: > On Tue, Sep 16, 2014 at 5:50 PM, Stefan Monnier > wrote: > > > The main problems I see with that: > > - Elisp is slow and as CPUs aren't getting faster, its slowness > > makes itself > > noticed more often. > > - Lack of some features, most notably FFI and concurrency. > > - Lack of manpower. > > > > Perhaps also the lack of possibility to enhance Emacs with code > written in other languages? I think for example that Javascript will > be something most future programmers will know. Could Guile make it > easier to enhance Emacs with Javascript (as an alternative to Elisp)? I think the (often-cited, not just here) idea of supporting multiple languages is a red herring, mostly. Every extension language supported adds some burden on those who want to understand what their editor does, not just use pre-packaged code. One of the great things about Emacs is that, once I know ELisp, I have a good chance of understanding and modifying any extension I see. And learning Emacs Lisp is not exactly hard. But we do not have to be all theoretical here. There is an editor which supports a dozen extension languages. The paradoxical thing to notice when you look at vim plugins is that most of them are written in VimL, including rather complex ones like NERD-tree and fugitive. I'd argue that VimL is a tiny bit harder to learn and use than ELisp. There are various reasons for why most plugins are written in it, but I do think that this is a pretty good indicator that the lack of "common" languages for extension is not exactly high on the list of problems for an editor. There are plenty of things in ELisp itself that I'd put much higher on that list. - Lack of a common structured datatype. While there's cl-defstruct, the support is a bit limited (C-h f does not work well with it), and a lot of code simply does not use it, making it seem a bit like a red-haired stepchild instead of a core recommended language feature. Alists and plists are usually used where modern languages would use structured datatypes, or even some hack with cons cells or lists and indexed access. - Hashes are one of those data types that are used all over the place in other languages, but you see them rarely in Emacs Lisp, again often losing out to alists and plists. This might be related to the standard library functions being a bit baroque. (There's some third-party hash library somewhere.) - Speaking of third-party libraries, s.el, dash.el and f.el provide things that really ought to be in core Emacs. - The regex engine is annoying to use. Providing some interface to PCRE would be a great step forward, and does not even have to be backwards-incompatible. - There are tons of warts in Emacs Lisp. nth vs. elt for example, with their exciting incompatible calling conventions. One thing I think would benefit Emacs Lisp as a language a lot would be a standard library cleanup. An effort to go through the libraries that come with Emacs, separate them into "standard library" and "extensions that come with Emacs", and then go through the "standard library", provide sane names when necessary (like setcar is provided for rplaca) and deprecating the old ones, or simply deprecate all but one version of functions with overlapping use (nth or elt, pick one). Finally, add standard libraries for common functionality that is currently lacking (see above). The next step would be going through the "extensions that come with Emacs" and make sure they all use namespace prefixes for anything but very specific commands meant for users to use with M-x. Only standard library functions are allowed to be namespace-free. These things would make Emacs Lisp a lot easier to use and also easier to learn for new users. This is all doable, but it needs manpower (#3 on Stefans list). Which is manpower that would not be doing other cool stuff on Emacs. Regards, Jorgen