From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?7KGw7ISx67mI?= Newsgroups: gmane.emacs.help Subject: Re: Why is Elisp slow? Date: Sun, 5 May 2019 12:07:06 +0900 Message-ID: <831BD780-F954-4E23-BF31-ED4E135C919B@icloud.com> References: <83muk4obfd.fsf@gnu.org> <20190502214006.4fdsinp7u5xuqvdv@Ergus> <20190503004416.xfuzzucflp6bxpuz@Ergus> <20190503103644.63lccjehmzulaojn@Ergus> <456EE4D4-F542-4F6A-B146-E6B9D72AE93B@icloud.com> <83tvebn1we.fsf@gnu.org> <20190503125832.44ovncaxp3vyjsla@Ergus> <20190504133218.g3ysx3ksuyvlthg3@Ergus> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="68572"; mail-complaints-to="usenet@blaine.gmane.org" Cc: help-gnu-emacs@gnu.org, Stefan Monnier To: Ergus Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun May 05 05:07:29 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hN7Uu-000Hgg-2i for geh-help-gnu-emacs@m.gmane.org; Sun, 05 May 2019 05:07:28 +0200 Original-Received: from localhost ([127.0.0.1]:35618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hN7Us-0000QG-Lo for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2019 23:07:26 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hN7Uf-0000Q0-6w for help-gnu-emacs@gnu.org; Sat, 04 May 2019 23:07:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hN7Ud-0000ej-NB for help-gnu-emacs@gnu.org; Sat, 04 May 2019 23:07:13 -0400 Original-Received: from pv50p00im-ztdg10012001.me.com ([17.58.6.51]:51137) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hN7Ud-0000dc-DT for help-gnu-emacs@gnu.org; Sat, 04 May 2019 23:07:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557025629; bh=pX7VwkWnc84lrB47L8BB2/fqhp5Nvx0D90h6VvyKhyY=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=Yvo84/Mq/Kre/DtgTd1betr6X/2ejPk3kCNmTsaRpHxr6TomK3bemUOCcb94RmYlZ j+NUFNv/0aZMq5ynFSCii7C20eZiltpyjnyWVtw6D+o8T8oT9L64IdA1VkituTpoKv WcmtUt4Ja5DuOenODcJtabHRAfjWQhSBY8kYamJUZpOlr/4yW1Kf9FjBJR3u/aAb3j DIIWqhXrjfixbbmkSiCASiSFZClRXCD4qDw9grMcPwxXmIWnFIzbtsHBB6EGYlEzf6 giaErBZxP35QmA+NLYVhlewWiUfDJk1KLAJZigq2Y0xvFhMojIZMC6pdnlC/hoChpX GwjozU9gGcfUQ== Original-Received: from [10.203.171.113] (unknown [223.38.18.21]) by pv50p00im-ztdg10012001.me.com (Postfix) with ESMTPSA id 69054280581; Sun, 5 May 2019 03:07:09 +0000 (UTC) X-Mailer: iPhone Mail (16E227) In-Reply-To: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-05_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=550 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905050027 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.51 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120201 Archived-At: The more I think about Guile Emacs and the Guile project itself, I start to t= hink that it=E2=80=99s not a problem of manpower, but something more fundame= ntal. Is it feasible (or even possible) to make two different high level lan= guages to interoperate in the engine level?=CC=8A=CC=88 For example, will it even make sense to have some Elisp macros in scheme lan= d, or even lua land, python land, JS land?=CC=8A=CC=88 Even if Emacs has limited success in these problem by e.g. transpiling JS to= elisp or doing macro expansion at runtime by the Elisp engine, I would like= a JSish API for emacs when writing packages, not a low level wrapper around= Elisp APIs. Same thing for Python, Lua, Scheme, etc... Different languages introduce different concepts that just don=E2=80=99t mat= ch. What would I do to use a Python module in JS?=CC=8A=CC=88 Unless the languag= e itself is designed to be easily interoperable with elisp by superseding co= ncepts (such as Clojure superseding Java), I=E2=80=99m pretty sure many peop= le won=E2=80=99t be satisfied in any kind of implementation.=20 CL is one (and presumably the only) case that (at least looks like) supersed= es Elisp in concepts. (Actually it would be something more like Elisp design= ed like that.) It=E2=80=99s a Lisp-2, it has macros, it uses S-exps, etc, et= c. It also has the advantage that we can leverage the state-of-art CL compil= ers that produce insane speeds from such a dynamic language. 2019. 5. 5. =EC=98=A4=EC=A0=84 9:43, Ergus =EC=9E=91=EC=84= =B1: > Hi Stefan: >=20 > I mostly agree with you and I get your points but I have some comments abo= ut. >=20 > On May 4, 2019 4:03:28 PM GMT+02:00, Stefan Monnier wrote: >>> Inter-language interaction (which is one of the strong features in >>> Guile out of the box) >>=20 >> That's fairly abstract (details matter: e.g. how are you going to use >> macros like `define-minor-mode` from non-Elisp languages?).=20 >>=20 >> Also while I much prefer Scheme to Elisp (or Common-Lisp for that >> matter), I'm not looking forward to maintaining Emacs packages in two >> (and more) different languages, and other maintainers are probably >> imagining such maintenance nightmare with a lot more dread than I. >>=20 >> So again: what are the advantages? >=20 > I totally agree with the complexity of mixing languages; but if we look ar= ound it is very difficult to attract new users and developers if they need t= o learn a new (old fashion) language only for Emacs (as I have been doing th= e last months). New programmers generations only know python and some C-like= languages but specially OOP and maybe is the moment to think a bit in the f= uture of the project more than in the past. Even if that implies taking some= risks and make hard desitions. Just give a look how popular are sublime tex= t or athom, that compared to Emacs those are kid toys. >=20 > So at some point it will be needed to make this desitions because the old d= evelopers will not live forever. I see the beauty of Lisp, but I am talking m= ore about a human issue here, that is more critical for Emacs right now and f= or the future. >=20 >> =46rom that point of view, moving Emacs to a Common-Lisp implementation >> would make more sense, since there is a chance we can *replace* Elisp >> with Common-Lisp in the long-run, rather than adding another language >> on >> the side. >>=20 > IF we could do so (embed the CL compiler as a submodule within emacs) and t= his can improve performance (while reduce the amount of code we need to main= tain, and the number of field experts we need to reach and attract ourself) I= 'll totally support such desition. It is not THE solution we need but it wil= l reduce some of the important issues. And will make the project development= more dynamic and sutainable. But if we can't take such desition right now i= s because we have few people to do the work and the new potential users/deve= lopers live in a different world with python java rust lua C++ Ruby but also= saturated of cheaper (easier to use and that do work without learning curve= ) alternatives like notepad++, visual studio code, geany, eclipse, kdevelop.= .. and so on. And some of them have put a lot of effort in improving the edi= ting capabilities, programming functionalities and ergonomy more than implem= enting a pdf reader or games withing the tool. So they only do one thing but= they do it right (or good enough for the user general needs) without initia= l configurations. >=20 > For the developers it is also easier to join to those projects because the= y are hosted on Github/gitlab with a more familiar workflow and interface, n= o copyright procedure, no mailing list.... and everything in the same please= and integrate with a fork based workflow. You can see where I'm going right= ? >=20 > I don't say that all this is better or worst than what we have, it is just= what the new generations understand, learn in the universities. Otherwise w= e are developing Emacs for us and the already existing users only. Ignoring w= here is the programming world now and where it is going. >=20 >=20 >>> and native compilation. >>=20 >> That's irrelevant. I think you mean "efficiency" or something like >> that. >> But that presumes that Elisp-on-Guile is indeed more efficient than >> Elisp-on-Emacs. Is there actual evidence that this is the case? >>=20 >> Also "efficiency" is broad: there's the execution time of some >> benchmarks, of course, but there's also the startup time, the VM size, >> the heap size, the GC interruptions, the time to load a big package >> (e.g. org-mode), ... >>=20 >> Guile would hopefully win on some of those, but by how much? >> And how much worse does it make the others? >>=20 >>> Plus some people taking care of the compiler/interpreter/virtual >>> machine parts and specialized in that specific section, which is good >>> because we need manpower. >>=20 >> AFAIC that's the main goal, indeed. >>=20 >> But last I checked Guile didn't have much manpower either. And there's >> a good chance that tracking Guile development (after switching to >> Guile) >=20 > Vicious circle no-projects-interested means no users with issues which mea= ns no potential developers. Any way I was talking about guile because it was= the official gnu language for extensions similar somehow to elisp and with a= full platform more or less ready to use without license issues. >=20 >> will also require manpower on Emacs's side. So it's not clear that it >> would turn out to be an advantage. >>=20 >>=20 >> Stefan >=20 > --=20 > Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi b= revedad. >=20