[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sqlite3
From: |
Alexandre Garreau |
Subject: |
Re: sqlite3 |
Date: |
Thu, 09 Dec 2021 06:52:07 +0100 |
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.
- Re: sqlite3, (continued)
- Re: sqlite3, Richard Stallman, 2021/12/17
- Re: sqlite3, Eli Zaretskii, 2021/12/18
- Re: sqlite3, Alexandre Garreau, 2021/12/09
- Re: sqlite3, Georges Ko, 2021/12/09
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/07
- Re: sqlite3, Pip Cet, 2021/12/08
- Re: sqlite3, Eli Zaretskii, 2021/12/08
- Re: sqlite3,
Alexandre Garreau <=
- Re: sqlite3, Pip Cet, 2021/12/09
- Re: sqlite3, Eli Zaretskii, 2021/12/09
- Re: sqlite3, Qiantan Hong, 2021/12/09
- Re: sqlite3, Michael Heerdegen, 2021/12/09
- Re: sqlite3, Qiantan Hong, 2021/12/10
- Re: sqlite3, Eli Zaretskii, 2021/12/10
- Re: sqlite3, Qiantan Hong, 2021/12/10
- Re: sqlite3, Eli Zaretskii, 2021/12/10
- Re: sqlite3, Michael Heerdegen, 2021/12/11
- Re: sqlite3, Michael Heerdegen, 2021/12/11