Re: sqlite3

[Alexandre Garreau]

Le mardo, 14-a de decembro 2021, 23-a horo kaj 1:33 CET Alan Mackenzie a 
écrit :
> 
> 
> > You've defined "inessential" in a way that happens to match your
> > particular usage patterns exactly.
> 
> Not at all.  I was using the word correctly.  In the words of Fowler,
> something is essential when "we have in mind a whole that would not be
> what it is to be or is or was if the part in question were wanting; the
> essential thing is such that the other thing is inconceivable without
> it.".  Emacs without gnus would still be Emacs.  Emacs without Lisp
> would not.  In that sense Lisp is essential to Emacs but gnus isn't.
> 
> That is an entirely different question as to what is necessary.
> Windscreen wipers are necessary on a motor car.  But wheels are
> essential.  I'm quite prepared to accept that gnus is necessary for
> Emacs.

I agree.

> > But for others, such as myself, Gnus and Org Mode are essential :-).
> 
> As above, they're not.  They're necessary.
> 
> I question the wisdom of adding more inessential stuff to the Emacs
> core. To be perfectly blunt, it is bloat.  I'm not saying that sqlite
> shouldn't be added to core.  But I am saying it should be questioned
> carefully, particularly by people who are familiar with it (which I'm
> not).

…but as said, sqlite, like *almost every* (well I doubt it’s possible to 
build emacs without ncurse support) library, is optional.  So talking 
about bloat is stretched, imho.

However, I feel like the core point that many must feel and that would 
justify all these lengthy and not always that much dense discussions is 
that SQLite is actually very useful, very demanded, very popular, and 
that’s precisely the problem.  SQLite has been described, as long with 
ZLib, as “one of the two most used software on the planet”, it’s almost 
everywhere, so the network effect is *extremely powerful* in their favor.

I feel that this power is feared, because then the fear that a dependency 
on sqlite *will* appear, as soon as it’s allowed, scares some users.  I 
understand the idea of “unlispiness” of it, personally, and I indeed feel 
we’re growing more akin to standard software than to the lisp world…

However I think the opposition has been very notably badly formulated, 
with little concrete examples of the issues, or precise and concrete 
desires (beside the “no binary files”… so you can edit with nano? well ok 
but you likely use emacs… we’re not 100% the unix philosophy either).  I 
think just integrating sqlite and *then* pointing out the issues may be 
more relevant.

I think the right mindset here has been best expressed by Qiantan, who 
tried to propose something instead of just say “no”.

> I feel sqlite has been added to the core, merged into master, with
> indecent haste, and without due reflection.  This cannot be good.  I
> think there are knowledgeable people here who are against this novelty
> and I think their expertise has been disregarded.  That cannot be good
> for the Emacs project.

Absolutely not, given the length of the discussion it’s pretty much the 
opposite.  We here have a paradox where the more we discuss it, the more 
the people who oppose talk, and the more we have the impression the 
opposition is strong, whatever are the arguments (even if they’re none, or 
they’re stated bad), and the consequence is that paradoxally we discussed 
a lot and yet we get the impression this is haste and without discussion.  
It’s the same paradox as in “[harsh criticism] —shut up” looks less like 
free expression than “[politically correct soft subpart of criticism]” 
(without “shut up” or counter-criticism).

It’s a little like unintentional, natural-occuring FUD.

Actually we won, lars added a per-file backend, so what he’s implementing 
isn’t even going to cause a dependency on sqlite anymore.  It’s even now 
actually fs-wide compatible with persist.el

I’m just sad, yet again, nobody worked with nobody else to try to 
advertise, discuss and agree the various already existing API at each 
point of the discussion.  Each person prefer their own API and well…