Re: sqlite3

[Alexandre Garreau]

Le merkredo, 8-a de decembro 2021, 19-a horo kaj 57:32 CET Eli Zaretskii a 
écrit :
> > Those are huge disadvantages. The benefits are not clear to me at all,
> > but they seem to revolve around the time it takes for an interrupted
> > or terminated session to restart?
> 
> No, the benefit is to be able to store and retrieve data from a
> persistent DB.  Python has it, Lua has it, JS has it, so why
> shouldn't Emacs be able to have it?

Because Emacs is Lisp, and is has “read” and “print”, that is, is 
homoiconic, while those are not.

But, on a similar perspective, we could argue JS has JSON, and yet all 
data is not stored as JSON (well: there is a strong tendency and desire to 
do that, as show some “modern” database such as mongodb).  Lua is very 
declarative and functional as well.

However lisp has a longer and stronger history of supporting 
inspectability, so the concern can be understood.  However, contrarily to 
the unix tradition, which modern emacses somewhat follow but which is 
younger than lisp, that doesn’t require everything to be in plaintext… 
just inspectable from lisp.  And if we build purely lisp interfaces, that 
will necessarily be the case, and we’ll even get elisp and emacs’ tools to 
inspect and treat generically sqlite databases (and that would be very 
neat! and hard to oppose to!), as long as the interface is general enough.

> > I don't think there are any applications for which the trade off (gain
> > some performance; lose some user freedom) is worth it, but even if
> > there are, we should look harder at alternatives which allow us to
> > gain similar amounts of performance without littering unsuspecting
> > users' .emacs.ds with binary-only files.
> 
> If you are right, then this capability will remain largely unused.
> Like Lisp threads, for example.  Let's talk in a couple of years.

No, absolutely not.  Not necessarily.  It could be used just because 
sqlite is a trend.  Just because it’s so much used that it looks cool.  By 
network effect.  Because people coming from different background would 
already know it (that’s an advantage for emacs), and get lazy to learn 
more lispy stuff (that’s a dramatic (but not that important) risk).

I mean many things which are not worth it are done netherless, that’s not 
an argument: imagine about if the vast majority of modern computation was 
done in ridiculously sandboxed javascript, tied to servers, and without a 
licence…

> > And we need to be careful about introducing this "as an option", of
> > course, because that means two versions of many packages' core code
> > need to be maintained, only one of which will be tested by users who
> > have not had the time to customize the defaults.
> 
> No, it means the packages that need such a capability will _require_
> Emacs with sqlite support.  Like any package that needs to display
> SVG requires Emacs with librsvg support, for example.

We could do that in some other way by taking care of atomistically not 
introduce sqlite without a higher-level “preferred” interface that would 
be encouraged for the simplest uses, and allow to select a different 
backend such as “gdbm”, “bare sexps”, etc.

If think the reason for the very emotional reaction here is the display of 
a fear, which has to be justified in some way, of the fact emacs may 
subbish a pressure to become “more like anything else”, that is less 
inspectable, less compatible, etc.