Re: performance isn't a concern in ... Emacs Lisp's future

[David Kastrup <dak@gnu.org>]

Nic Ferrier <nferrier@ferrier.me.uk> writes:

> phillip.lord@newcastle.ac.uk (Phillip Lord) writes:
>
>> What can I say? I don't sit around waiting for emacs to do stuff
>> nowadays when I am using it. And I've just implemented a package that
>> copies, then searches and replaces an entire buffer on every keypress.
>> And I don't notice it running for moderate size files.
>>
>> The manual talks about the performance danger of overlay, but I've just
>> put an overlay an every word in a 300 line buffer, and I can't notice
>> that either.
>>
>> Even though Emacs now takes considerably more than Eight Megabytes, it
>> is not Constantly Swapping. CPU has grown quicker than Emacs demands.
>
> Another reason is we learned how to write better code. In the old days
> we'd all be hacking 10k line C++ files.

In the old days there was no C++.  There still isn't in the Emacs
codebase, and src/xdisp.c has 30k lines.

> But programmers with that level of maturity are still around.  Many of
> them using Eclipse.

Shrug.  I've written cross compiler and assembler for FORTH systems
fitting into a few kilobytes and not even organized into files but
rather 1kB blocks of source code for compiling industrial applications.
I had to write bootstrap loader and BIOS for my first self-soldered
system before being able to boot the first time.

I can probably still rattle off the execution cycles for most Z80
assembly language commands and (from a later job) most of those for
Pentium I (though I'm fuzzy these days what the second integer pipeline
was not getting used for).

I am sure you'll find better reasons to call me immature than my too
long computing history purportedly rendering me unable to write good
code.

By the way: one of the most lucid pieces of code I had the pleasure to
come across was a Reversi program written in Z80 assembly language for
which only had the binaries and needed to disassemble it in order to
adapt it to a different OS and storage location.  It was a textbook
variant of Alpha-Beta pruning with scoring tables mapped excellently to
the processor architecture, using the index registers very consistently,
and with the code structured into clearly recognizable tasks.

No, we haven't really "learned how to write better code", just like
electronic instruments have not taught us how to write better music.

Having a larger variety of wrappings for content does not really change
what substance actually lies at the core.

-- 
David Kastrup