From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Marcin Borkowski Newsgroups: gmane.emacs.help Subject: Re: Why is Elisp slow? Date: Sat, 04 May 2019 13:52:51 +0200 Message-ID: <87h8aajv1o.fsf@mbork.pl> References: <86o9c4np6q.fsf_-_@zoho.com> <8636tfocyl.fsf@zoho.com> <20190502075617.GA18331@tuxteam.de> <874l6d3ylg.fsf@mbork.pl> <20190502131827.GA28987@tuxteam.de> <83k1f8q39o.fsf@gnu.org> <87zho43c13.fsf@mbork.pl> <20190502200000.GK28987@tuxteam.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="199160"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: mu4e 1.1.0; emacs 27.0.50 Cc: help-gnu-emacs@gnu.org To: tomas@tuxteam.de Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat May 04 13:54:35 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 1hMtFS-000pfq-Tx for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2019 13:54:35 +0200 Original-Received: from localhost ([127.0.0.1]:55090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMtFR-00042k-Rc for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2019 07:54:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMtFG-00041p-1g for help-gnu-emacs@gnu.org; Sat, 04 May 2019 07:54:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMtFE-0004Sy-QG for help-gnu-emacs@gnu.org; Sat, 04 May 2019 07:54:21 -0400 Original-Received: from mail.mojserwer.eu ([195.110.48.8]:50690) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMtFE-0004Pi-JF for help-gnu-emacs@gnu.org; Sat, 04 May 2019 07:54:20 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id 37CBAE6722; Sat, 4 May 2019 13:54:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.mojserwer.eu Original-Received: from mail.mojserwer.eu ([127.0.0.1]) by localhost (mail.mojserwer.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdMfqm0tYuQN; Sat, 4 May 2019 13:54:08 +0200 (CEST) Original-Received: from localhost (83.25.57.1.ipv4.supernova.orange.pl [83.25.57.1]) by mail.mojserwer.eu (Postfix) with ESMTPSA id 76C2BE63F4; Sat, 4 May 2019 13:54:08 +0200 (CEST) In-reply-to: <20190502200000.GK28987@tuxteam.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.110.48.8 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:120185 Archived-At: On 2019-05-02, at 22:00, tomas@tuxteam.de wrote: > On Thu, May 02, 2019 at 09:13:28PM +0200, Marcin Borkowski wrote: > > [...] > >> > (My personal rant to package authors is that they are way too eager to >> > implement stuff in Lisp which cannot possibly be fast enough or >> > scalable enough, instead of urging Emacs to provide new C primitives >> > and core features, or, better, submitting patches to implement such >> > features in C. Two cases in point are linum-mode and fci-mode. End >> > of rant.) >> >> That is an interesting POV, although I'm not sure if I agree. IOW, >> I fully understand why people might do so. I, for one, consider myself >> pretty fluent in Elisp and hardly literate in C. > > This approach is known as "Ousterhout's dichotomy" [1], after John Ousterhout, > author of Tcl (which was conceived as a very simple scripting language > meant to extend existing applications). Tcl grew later a bytecode > interpreter (as did elisp) -- making the C interface significantly > more complex (but the interpreter significantly faster). > > Walking the trade-off between simple and efficient is interesting. Thanks. As usual, I learned something new from you... Best, -- Marcin Borkowski http://mbork.pl