Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[xenodasein--- via Emacs development discussions.]

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02223.html
From: dick.r.chiang@gmail.com

> You make it sound as if he doesn't relish the convo.

> Uninformed lookie-loos such as xenodasein do fly-by's all the time, and
> the usual suspects from this list take the bait.  And why wouldn't they?
> It's much easier and more gratifying putting these unheralded
> know-it-all's in their place, than writing code and fixing bugs.

> I wonder if our maintainer wears a toga.  He's really nailed down the
> Hippocratic Oath of "first, do no harm" (the corollary of which is
> "don't move fast and don't break things"), and his Socratic approach to
> answering questions by asking five more is masterful.

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[xenodasein--- via Emacs development discussions.]

Hello to you too, broseph.  I suppose it takes a special kind of
grey matter to consider asking questions being a know-it-all. :)

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01968.html
From: Po Lu
Date: Tue, 21 Dec 2021 09:06:40 +0800

> It's not much more modular than what we have in Emacs. The only real
> difference is that it runs in a separate process, which I think also
> poses freedom issues. AFAIK there is at least one proprietary frontend
> for neovim.

I don't know if it is more or much more, but credit where credit is due.
This does help them receive more contributions than both Vim and Emacs.
Structuring the code with respect to software freedom is a whole different
subject, (which I support) but current ifdef toolkit jungle is not that.

> Details, please. We want to fix any bugs that crop up anywhere, and I
> don't think we're missing out on any features.

I cannot see the future or what could've been, this is highly opinionated
but I do believe following latest C standard as early as possible is good
for an open source project.

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I cannot see the future or what could've been, this is highly opinionated
  > but I do believe following latest C standard as early as possible is good
  > for an ...

As has been pointed out, we support lots of platforms, including old
platforms, and some of them don't have fresh new compilers.  If we
wanted to be quick to tell users "tough, your platform is no longer
supported," we could assume everyone has the latest GCC to use.
But those platforms are important.

Some of those old platforms are among the most important ones
because they allow operation without the Intel Management Engine
(or AMD's counterpart to that).

Our principles say we must do our best to encourage people to use a
free compiler if that is at all possible.  If the only C17 compiler
for a platform is nonfree, we must support using GCC instead.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>   > I cannot see the future or what could've been, this is highly opinionated
>   > but I do believe following latest C standard as early as possible is good
>   > for an ...
>
> As has been pointed out, we support lots of platforms, including old
> platforms, and some of them don't have fresh new compilers.  If we
> wanted to be quick to tell users "tough, your platform is no longer
> supported," we could assume everyone has the latest GCC to use.

This is not about having the latest GCC, this is about having a GCC
that's less than 10 years old.

> But those platforms are important.
>
> Some of those old platforms are among the most important ones
> because they allow operation without the Intel Management Engine
> (or AMD's counterpart to that).

Aren't there modern machines without this? Machines that are much more
performant, reliable and secure than those old ones, which usually are
tied to an unsupported OS full of security defects?

I sincerely don't get the stance of clinging to decades-old software and
hardware but when it comes to Emacs it must be the latest and shiniest.
As if emacs version N would cease to work the very moment emacs version
N+1 is released.

Have we checked lately if those machines that we purport to support are
able to run anything more complex than `emacs -Q'?

> Our principles say we must do our best to encourage people to use a
> free compiler if that is at all possible.  If the only C17 compiler
> for a platform is nonfree, we must support using GCC instead.

Nobody suggested using anything else than GCC.

I'm having the feeling that a good chunk of participants on this ml are
unwittingly but firmly commited to confine Emacs to the same
retro-computing world they live in.

The amount of tension and obstructionism that emerges every time that
someone suggests implementing some technology less than 20 years old is
overwhelming.

Re: Development Speed

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 11:09:09 +0100
> 
> The amount of tension and obstructionism that emerges every time that
> someone suggests implementing some technology less than 20 years old is
> overwhelming.

Generalizations are almost always risking losing accuracy, but this
one does that with a vengeance.  I think it's not only inaccurate
(when talking about Emacs development), but also simply unfair.  E.g.,
some of the recent developments in Emacs use technology that is much
newer than "20 years", and I challenge you to come up with examples
that could back up your generalization, or even come close.

Re: Development Speed

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 22 Dec 2021 11:09:09 +0100
>> 
>> The amount of tension and obstructionism that emerges every time that
>> someone suggests implementing some technology less than 20 years old is
>> overwhelming.
>
> Generalizations are almost always risking losing accuracy, but this
> one does that with a vengeance.  I think it's not only inaccurate
> (when talking about Emacs development), but also simply unfair.  E.g.,
> some of the recent developments in Emacs use technology that is much
> newer than "20 years", and I challenge you to come up with examples
> that could back up your generalization, or even come close.

Example: the painful road from CVS to a modern VC system (first bzr and
then Git when was clear that bzr was inadequate at several levels, as
some warned before it was adopted.) And then many contributors didn't
bother to adapt to the distributed workflow and keep using Git as if it
were CVS, which makes the VC history hard to follow and of diminished
value.

Another example: the mailing list used as a bug tracker. We went from no
tracker at all to a big hack that happens to accommodate the personal
preferences of a few contributors while making things harder for
everyone else. Basic things like subscribing to a bug are too advanced:
you either monitor the mailing list or out of touch.

Another example: the amount of old cruft and hacks that pervades the
source code, prominently the C part.

The motif port was re-enabled with the excuse of two users saying that
they use it (two users! which actually didn't actually said that they
use the port, just that they build it.)

A the same time someone suggested experimenting with a new approach to
display and he was shunned ("We tried with such a library, many eons
ago. It was named lwlib, and you can judge for yourself how successful
it is.") Right, because if it failed many eons ago, trying again is
doomed to fail for sure, as technologies in software change as often as
in medieval masonry; and what the OP was suggesting is not what lwlib
does, IIUC.

So we maintain old code because two people "complain" (they didn't) and
meet with... let's say skepticism, proposals that seem to require
significant changes on the source base but with a high impact on
improving Emacs' potential. Lots of features and fixes are made trying
to not change the "stable" code, that's why we end having functions over
1000 lines long sprinkled with #ifdefs, which not only make any
substantial change very difficult, but are a big red sign saying "here
be dragons."

Emacs' architecture favors plug-in components, in the form of Elisp
packages, external processes and C libraries exposed to Elisp. That's
what keeps Emacs somewhat competitive, often thanks to heroic efforts.
But working on certain key parts of the core is very hard, both
technically and socially. You are concerned about the lack of C
contributors, but I think your worries are not well focused: there are
still plenty of C hackers around, but do they see our C core as
something they would enjoy contributing to?

Can we give Eli a break, please? [ Was: Re: Development Speed ]

[Alan Mackenzie]

Hello, Óscar.

On Wed, Dec 22, 2021 at 16:51:41 +0100, Óscar Fuentes wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> From: Óscar Fuentes <ofv@wanadoo.es>
> >> Date: Wed, 22 Dec 2021 11:09:09 +0100

> >> The amount of tension and obstructionism that emerges every time that
> >> someone suggests implementing some technology less than 20 years old is
> >> overwhelming.

> > Generalizations are almost always risking losing accuracy, but this
> > one does that with a vengeance.  I think it's not only inaccurate
> > (when talking about Emacs development), but also simply unfair.  E.g.,
> > some of the recent developments in Emacs use technology that is much
> > newer than "20 years", and I challenge you to come up with examples
> > that could back up your generalization, or even come close.

Your last post comes over as one big moan.  You moan about perfectly
valid decisions, some of which didn't turn out optimally.  You moan about
perfectly valid decisions, full stop.  You or somebody else could have
moaned about the opposite decisions, had they been so taken, equally
well.

The main point of my post is that Eli is having to deal with a lot of
negative posting at the moment, and this is a Bad Thing.  He could do
with a break.

We're approaching what is in large swathes of the world the "season of
goodwill".  Why don't we reflect that in our posts to emacs-devel, in
particular to those directed at Eli?

I'm not going to respond to your points in detail; that would just lead
to more interminable arguments.  Suffice it to say that I disagree with
most of them as well as disliking the tone they were expressed in.

A happy Christmas to you!

> Example: the painful road from CVS to a modern VC system (first bzr and
> then Git when was clear that bzr was inadequate at several levels, as
> some warned before it was adopted.) And then many contributors didn't
> bother to adapt to the distributed workflow and keep using Git as if it
> were CVS, which makes the VC history hard to follow and of diminished
> value.

> Another example: the mailing list used as a bug tracker. We went from no
> tracker at all to a big hack that happens to accommodate the personal
> preferences of a few contributors while making things harder for
> everyone else. Basic things like subscribing to a bug are too advanced:
> you either monitor the mailing list or out of touch.

> Another example: the amount of old cruft and hacks that pervades the
> source code, prominently the C part.

> The motif port was re-enabled with the excuse of two users saying that
> they use it (two users! which actually didn't actually said that they
> use the port, just that they build it.)

> A the same time someone suggested experimenting with a new approach to
> display and he was shunned ("We tried with such a library, many eons
> ago. It was named lwlib, and you can judge for yourself how successful
> it is.") Right, because if it failed many eons ago, trying again is
> doomed to fail for sure, as technologies in software change as often as
> in medieval masonry; and what the OP was suggesting is not what lwlib
> does, IIUC.

> So we maintain old code because two people "complain" (they didn't) and
> meet with... let's say skepticism, proposals that seem to require
> significant changes on the source base but with a high impact on
> improving Emacs' potential. Lots of features and fixes are made trying
> to not change the "stable" code, that's why we end having functions over
> 1000 lines long sprinkled with #ifdefs, which not only make any
> substantial change very difficult, but are a big red sign saying "here
> be dragons."

> Emacs' architecture favors plug-in components, in the form of Elisp
> packages, external processes and C libraries exposed to Elisp. That's
> what keeps Emacs somewhat competitive, often thanks to heroic efforts.
> But working on certain key parts of the core is very hard, both
> technically and socially. You are concerned about the lack of C
> contributors, but I think your worries are not well focused: there are
> still plenty of C hackers around, but do they see our C core as
> something they would enjoy contributing to?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> Your last post comes over as one big moan.  You moan about perfectly
> valid decisions, some of which didn't turn out optimally.  You moan about
> perfectly valid decisions, full stop.

That's your opinion. It's understandable that you talk about "perfectly
valid decisions", since you were strongly vocal when those decisions
were made and had a significant impact on them. Which is fine.

> The main point of my post is that Eli is having to deal with a lot of
> negative posting at the moment,

I'm pretty sure that Eli:

1. knows how much I appreciate his work.

2. is quite capable of speaking for himself.

3. any observation on my messages is not addressed to him personally,
   but to the project as a whole, since a long time before he was the
   maintainer. BTW, I energetically lobbied for using bzr over git at
   the time and thought that debbugs were better than nothing. I was as
   wrong as the wrongest (non-)participant on those discussions.

> We're approaching what is in large swathes of the world the "season of
> goodwill".

I'll refrain from expressing my opinion about the concept of seasonal
goodwill.

Finally, I will say that you are not the only one who feels entitled to
moan and rant on emacs-devel :-)

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[dick]

AM> He could do with a break.

You make it sound as if he doesn't relish the convo.

Uninformed lookie-loos such as xenodasein do fly-by's all the time, and
the usual suspects from this list take the bait.  And why wouldn't they?
It's much easier and more gratifying putting these unheralded
know-it-all's in their place, than writing code and fixing bugs.

I wonder if our maintainer wears a toga.  He's really nailed down the
Hippocratic Oath of "first, do no harm" (the corollary of which is
"don't move fast and don't break things"), and his Socratic approach to
answering questions by asking five more is masterful.

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 12:12:39 -0500
> 
> Uninformed lookie-loos such as xenodasein do fly-by's all the time, and
> the usual suspects from this list take the bait.  And why wouldn't they?
> It's much easier and more gratifying putting these unheralded
> know-it-all's in their place, than writing code and fixing bugs.

I consider it part of my job to participate in discussions related to
Emacs development where I think I have something potentially useful to
say.

But thank you so much for you kind offer of managing my time and
tasks.