emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sqlite3


From: Alan Mackenzie
Subject: Re: sqlite3
Date: Fri, 10 Dec 2021 21:25:05 +0000

Hello, Eli and Emacs.

On Wed, Dec 08, 2021 at 15:14:08 +0200, Eli Zaretskii wrote:
> > From: Qiantan Hong <qhong@mit.edu>
> > Date: Wed, 8 Dec 2021 05:41:17 +0000
> > Cc: Po Lu <luangruo@yahoo.com>, Eric Abrahamsen <eric@ericabrahamsen.net>,
> >  cesar mena <cesar.mena@gmail.com>, "emacs-devel@gnu.org" 
> > <emacs-devel@gnu.org>

> > I’m against using sqlite3, or maybe in general any database.

> Why would you be against adding to Emacs infrastructure that might be
> useful for some applications?

Because it can degrade other applications.  Primarily Emacs is a
programmers' text editor, and I would like it to stay that way.  Adding
database functionality is inessential to that prime function (regardless
of how important it might be), therefore is a burden to that prime
function.  All things like gnus, org-mode are likewise inessential -
they add many megabytes to the source-code, greatly increase build time,
take up key-bindings, space in documentation (hopefully ;-) and so on.

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.

> We didn't yet decide what would be the policy and guidelines for using
> this in Emacs, but there should be no doubt that when we do make those
> decisions, we will take into considerations all the factors that you
> mentioned, and more.  Because Lars, myself, and all the others here
> are quite aware of the needs and the advantages/disadvantages, and we
> use and develop Emacs long enough to understand what is and what isn't
> Emacs'y.  So the decisions, when they are made, will not be silly or
> haphazard.  Rest assured that where using simple text files is
> adequate, no one in their right mind will advocate using a DB.

> I see no reason to be "against sqlite3".  Many popular software
> packages out there have similar capabilities, so why shouldn't Emacs
> offer them as well?  Just because it can be abused?  If that's the
> reason, we'd need to "be against" almost every advanced Emacs feature,
> and I personally would go over the display engine and butcher it to
> remove every single advanced feature that people are known to abuse.
> Would that make sense?  I hope not.

I disagree with you (Eli), that we should not anticipate and be wary of
how people might use things.  As an example, Richard warned me a few
years ago against introducing a hook for changes in narrowing, saying
that it was too powerful, and would end up with users using it in ways
which would cause us lots of trouble.

Similarly, look at what has happened to the humble web brower - it
started as a browser for the web, and has in recent years transformed
into an execution engine for (usually) none-free and often hostile
scripts.  Would this have happened had somebody not developed
JavaScript?  I miss the web browser of old.

Similarly, I would be very unhappy if somebody transformed Emacs into a
database engine, where its prime features were unusable without the
database features being built in.  I think this possibility, remote at
this juncture, should be borne in mind.

> So please, can you drop this "against sqlite3" attitude, and let Lars
> finish the job he started?  Adding capabilities to Emacs, and in
> particular providing us with interfaces to modern technologies, is
> supposed to be a Good Thing, something that advances Emacs and makes
> it a better, more capable platform for developing useful applications.
> It's our way to survive in the long run.  Let's not shoot ourselves in
> the foot due to myopic perspectives.

As above, I don't agree entirely with this perspective.

> TIA

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]