[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shrinking the C core
From: |
Eric Frederickson |
Subject: |
Re: Shrinking the C core |
Date: |
Wed, 09 Aug 2023 20:58:10 -0500 |
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Po Lu <luangruo@yahoo.com>:
>> "Eric S. Raymond" <esr@thyrsus.com> 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
> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
- Shrinking the C core, Eric S. Raymond, 2023/08/09
- Re: Shrinking the C core, Andreas Schwab, 2023/08/09
- Re: Shrinking the C core, Po Lu, 2023/08/09
- Re: Shrinking the C core, Eric S. Raymond, 2023/08/09
- Re: Shrinking the C core, Po Lu, 2023/08/09
- Re: Shrinking the C core, Eric S. Raymond, 2023/08/09
- Re: Shrinking the C core, Christopher Dimech, 2023/08/09
- Re: Shrinking the C core,
Eric Frederickson <=
- Re: Shrinking the C core, Sam James, 2023/08/09
- Re: Shrinking the C core, Po Lu, 2023/08/09
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/10
- Re: Shrinking the C core, Eric S. Raymond, 2023/08/10
- Re: Shrinking the C core, Eric S. Raymond, 2023/08/10
- Re: Shrinking the C core, Emanuel Berg, 2023/08/11
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/11
- Re: Shrinking the C core, Emanuel Berg, 2023/08/11
- Re: Shrinking the C core, Eli Zaretskii, 2023/08/11
- Re: Shrinking the C core, Emanuel Berg, 2023/08/11