From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Frederickson Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Wed, 09 Aug 2023 20:58:10 -0500 Message-ID: <87ttt7odzh.fsf@arch.mail-host-address-is-not-set> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31572"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 10 03:59:05 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qTux6-00080G-OR for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Aug 2023 03:59:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qTuwM-0000I2-U1; Wed, 09 Aug 2023 21:58:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTuwL-0000Hu-LS for emacs-devel@gnu.org; Wed, 09 Aug 2023 21:58:17 -0400 Original-Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qTuwJ-0005ag-Oc for emacs-devel@gnu.org; Wed, 09 Aug 2023 21:58:17 -0400 Original-Received: by mail-io1-xd34.google.com with SMTP id ca18e2360f4ac-7909808a504so14373339f.1 for ; Wed, 09 Aug 2023 18:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691632694; x=1692237494; h=mime-version:message-id:date:cc:references:in-reply-to:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=GaVZMm8/F7nshrCcvg7OMWqUxOBUkxk5kuow1gIXjLI=; b=J3uQ/PrW4Z0GgKTqd2x18AcxGu73WsW6OY9KjZsjhiscD6Hbu+TQRdJ+cgywLEELn0 2IciXsr6O3Em3sCQImbXTbPYDlCoy+FOqMwAVvZ5dvZcKN4jCTrVXM5rwJ5ycH2/CU35 mxa2twt8t/t7WvfbFH1m5THvJDd1KzaX4bwVTKqmlwJ45gPfvk5baXlsJI6948uV5lIw Q5zl+f5HFQ/jqV3GLuUM4PGyIAuFdjCOdsu56H2NVGsB3aZ9Zd8LeIx0oWXxnKD09qqk XaWg/1uGO2gltUwiarTOlDTEy4ZXRljhfH825ofWyG1JjfzyRdAuFili84dLlgGV6PjL MtEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691632694; x=1692237494; h=mime-version:message-id:date:cc:references:in-reply-to:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GaVZMm8/F7nshrCcvg7OMWqUxOBUkxk5kuow1gIXjLI=; b=G064nDRA4N3XvzHAspl5GkggkOuhIYO6kVvPAZBFRvOdfkPsD0Mj5UbQltobtWADcS 5vfYV4JD/AxEfHKH/IXxAPGBuZnV/X8EHvZFYfhS8WPKlbCBewi5IIBfaxXIrNBwfviF fhfXEze8m0xvBMgbsDt84UdOKjNtR/VN/1FKz68ugNgUF2KVIvfHAukEso17dhSKgV1U ZCmrscmooseOmbuGDhUbkJ1xTF7hSa88H/r3LvhflJlHwu+h80artJykL9oWGHxF38GA ZjsOvdEX4l0fyhBneGz2hKEp37XIKoZA/8Ox5uyD22ItAUmqv/gtE++sfAxo1H3AmCLi tRnA== X-Gm-Message-State: AOJu0Yzkc8/4VxpZ8XOMuS9chcIP3iFC+Cgvlt4tckQJ12BjrGuaqpFl wxbu6UPTmYuyJJGIXu0cqZuYd7xoYtJFfA== X-Google-Smtp-Source: AGHT+IHcWZqTI834nO7pNACsgndvkKhWMwk5A067x2k5pbsbl5jRdmXMTT8A18kqh4VnkFcwUN96wQ== X-Received: by 2002:a05:6602:3348:b0:790:c461:6f34 with SMTP id c8-20020a056602334800b00790c4616f34mr1697103ioz.3.1691632693967; Wed, 09 Aug 2023 18:58:13 -0700 (PDT) Original-Received: from localhost ([2604:2d80:6704:d700:66c:59ff:feb0:491f]) by smtp.gmail.com with ESMTPSA id w3-20020a5d9cc3000000b00783b0780bd8sm156433iow.4.2023.08.09.18.58.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Aug 2023 18:58:13 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::d34; envelope-from=ericfrederickson68@gmail.com; helo=mail-io1-xd34.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308499 Archived-At: "Eric S. Raymond" writes: > Po Lu : >> "Eric S. Raymond" writes: >> >> > When I first worked on Emacs code in the 1980s Lisp was already fast >> > enough, and machine speeds have gone up by something like 10^3 since. >> > I plain don't believe the "slower" part can be an issue on modern >> > hardware, not even on tiny SBCs. >> >> Can you promise the same, if your changes are not restricted to one or >> two functions in fileio.c, but instead pervade throughout C source? > > Yes, in fact, I can. Because if by some miracle we were able to > instantly rewrite the entirety of Emacs in Python (which I'm not > advocating, I chose it because it's the slowest of the major modern > scripting languages) basic considerations of clocks per second would > predict it to run a *dead minimum* of two orders of magnitude faster > than the Emacs of, say, 1990. > > And 1990 Emacs was already way fast enough for the human eye and > brain, which can't even register interface lag of less than 0.17 > seconds (look up the story of Jef Raskin and how he exploited this > psychophysical fact in the design of the Canon Cat sometime; it's very > instructive). The human auditory system can perceive finer timeslices, > down to about 0.02s in skilled musicians, but we're not using elisp > for audio signal processing. > > If you take away nothing else from this conversation, at least get it > through your head that "more Lisp might make Emacs too slow" is a > deeply, *deeply* silly idea. It's 2023 and the only ways you can make > a user-facing program slow enough for response lag to be noticeable > are disk latency on spinning rust, network round-trips, or operations > with a superlinear big-O in critical paths. Mere interpretive overhead > won't do it. > >> Finally, you haven't addressed the remainder of the reasons I itemized. > > They were too obvious, describing problems that competent software > engineers know how to prevent or hedge against, and you addressed me > as though I were a n00b that just fell off a cabbage truck. My > earliest contributions to Emacs were done so long ago that they > predated the systematic Changelog convention; have you heard the > expression "teaching your grandmother to suck eggs"? My patience for > that sort of thing is limited. Sorry to jump in, but I can't resist. You're critical of others for not showing you deep respect as a Developer of the Highest Caliber, and yet you act with the absurd intention of "sneaking up on" changes? And then refuse to reveal your apparently grand intentions underlying this sleight-of-hand project? Emacs is a program that I and many thousands of others rely on every day to get work done; please don't pollute its development ecosystem with that utter nonsense. - Eric Frederickson > -- > Eric S. Raymond