Re: sqlite3

[Karl Fogel <kfogel@red-bean.com>]

On 10 Dec 2021, Alan Mackenzie wrote:
>I've never used org-mode in my life, and only tried out gnus 
>once,
>around 20 years ago, when it was too slow and too complicated for 
>me.
>Yet I have to pay the costs of these packages every time I build 
>Emacs
>bootstrap.
>
>I'm not arguing for a removal of these things, which are clearly 
>good.
>But I think it is reasonable to question the wisdom of adding 
>more
>inessential stuff.

You've defined "inessential" in a way that happens to match your 
particular usage patterns exactly.  But for others, such as 
myself, Gnus and Org Mode are essential :-).

In a thread from 2020 ([1], "GNU Emacs raison d'etre"), I offered 
a different understanding of Emacs's essence:

It is the editing environment that best rewards sustained user 
investment.

That differs from your claim that "primarily Emacs is a 
programmers' text editor".  Programming Emacs is simply the 
highest level of investment, but it doesn't necessarly imply that 
one is using Emacs *for* computer programming -- often, I'm not. 
Naturally, users who are programmers are going to have the easiest 
time investing in their Emacs experience, both due to skills they 
have and (probably) due to being temperamentally inclined towards 
patience with such investments. 

The argument for sqlite3 (or something like it) is that it makes 
some of those investments easier -- specifically, it makes it 
easier to do things that involve selective access to large 
datasets.

A concrete example is https://code.librehq.com/kfogel/mailaprop/. 
Right now, I load all the data in to memory at startup time right, 
but it's costly -- it noticeably slows down startup.  Fortunately, 
I don't restart Emacs very often, so this is liveable.  However, 
if the dataset were 10x or 20x larger, it would be intolerable.

I could of course try out the existing 3rd-party sqlite3 library 
for Emacs; it's not like there's a huge barrier here.  But still, 
that would mean adding a dependency that I don't currently have. 
Whereas if the facility were built into Emacs, the barrier would 
be lower, so I'd be more likely to experiment with selective 
loading of such datasets.  Presumably, the same argument applies 
to others' applications as well, and we'd have the further 
advantage that everyone would be using a common facility, so it 
could be improved collaboratively.

I believe this is one of the points Lars is making.

Best regards,
-Karl

[1] 
https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01855.html
    From: Karl Fogel <kfogel@red-bean.com>
    To: <emacs-devel@gnu.org>
    Subject: Re: GNU Emacs raison d'etre
    Date: Wed, 13 May 2020 11:18:50 -0500
    Message-ID: <871rnnvmdx.fsf@red-bean.com>