From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sam James Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Thu, 10 Aug 2023 03:07:58 +0100 Organization: Gentoo Message-ID: <87leej7ima.fsf@gentoo.org> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> <87ttt7odzh.fsf@arch.mail-host-address-is-not-set> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7142"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.10.4; emacs 30.0.50 Cc: esr@thyrsus.com, emacs-devel@gnu.org To: Eric Frederickson Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 10 04:11:04 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 1qTv8h-0001fN-QX for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Aug 2023 04:11:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qTv83-0003Ce-Mq; Wed, 09 Aug 2023 22:10:23 -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 1qTv82-0003CD-0x for emacs-devel@gnu.org; Wed, 09 Aug 2023 22:10:22 -0400 Original-Received: from dev.gentoo.org ([2001:470:ea4a:1:5054:ff:fec7:86e4] helo=smtp.gentoo.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1qTv7y-0007ea-Vw for emacs-devel@gnu.org; Wed, 09 Aug 2023 22:10:21 -0400 In-reply-to: <87ttt7odzh.fsf@arch.mail-host-address-is-not-set> Received-SPF: pass client-ip=2001:470:ea4a:1:5054:ff:fec7:86e4; envelope-from=sam@gentoo.org; helo=smtp.gentoo.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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:308500 Archived-At: Eric Frederickson writes: > "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? While not being up front about the changes is of debatable wisdom, I didn't find it particularly alarming given I at least have always understood the aim to be to have the C core as small as possible anyway. I presume esr was under the same impression and hence even if he never went through with his big plan, it'd be some easy wins from his perspective. Laying the groundwork for something that may or may not come off with independent changes one believes are worthwhile isn't underhanded if it's just a pipedream in the back of your head but you think the changes are good in isolation.