Re: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA

[xenodasein]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00821.html
> ...
> > All arguments against Drew's proposals so far converge at "it is better
> > to do nothing."
>
> No, that is not what is being said. I'm saying "There is nothing needing
> to be done." It is an unnecessary change with little, if any, real
> benefit for users and which will have unnecessary/unwanted impact on
> some existing users.
>
> > Why not propose something even better?
>
> Better than what? Exactly what problem will this change address and how
> does this problem impact users and how does the proposed change mitigate
> that impact?

Well, I think we are getting there on this thread.

> > Throwing "where
> > is your evidence?" around is easy, but one must consider we are far from
> > the domain of scientific method here, or of law.
>
> IF you propose a change, it has to be backed up with justification. Just
> saying it would be better is insufficient.  So far, the justification
> seems to be it is better from a philosophical/theoretical standpoint not
> to mix user generated and auto-generated code in the same file,
> it could reduce accidental errors by the user editing the settings or the user
> finds it
> confusing and the warning scares them.
>
> > Is existence of people
> > on Emacs related forums suggesting setting custom-file to /dev/null as a
> > good solution evidence enough?
>
> I think all that is evidence of is bad advice. Why would you set your
> custom file to /dev/null? If you don't like custom, don't use it. If you
> do use it, that advice will likely just totally confuse you as now, if
> when you do use custom, it won't work.

Yes, but such advice is then also evidence to that some users are
annoyed enough with the current (bad) behavior to do/talk about things
like that.

> > How about split of early-init/creation
> > of straight.el?
>
> iWhat about it? How is it relevant to this proposed change?

Suffice it to say that Customize and package.el modifying init.el
was used as a driving factor in creating some popular alternative
package managers.

> > What you call "belief/ideology" is known as intuition,
> > and it is the primary force behind any successful software.
> > Or any
> > kind of invention, really.
>
> What is being proposed here is an impacting change to existing
> behaviour. Trying to claim such a change is 'innovative' or can be
> justified by intuition is simply insufficient. If it is a good change,
> then it should not be difficult to provide sufficient justification.
> Intuition can be both good and bad. There has to be some way to assess
> whether intuition (or an idea) is a good one - just saying it is
> intuition is not enough. 
>
> In over 30 years of working on software projects, some successful, some
> less so, I can say with confidence, those projects which failed were
> frequently those projects which did not manage change and were
> constantly making changes based on little else other than intuition. The
> projects which succeeded were the ones which correctly assessed which
> changes to do and which ones not to. Intuition seldom comes into it, but
> when it does, it is backed up with sufficient justification to offset
> any of the negative consequences.

Apart from miscommunication, we actually think the same on this.  Good
intuition and changes lead to success, bad to failure.  I doubt "ones
which correctly assessed" used rigorous formal methods to arrive at their
decisions, I presume they did what we do on this list, talk over it.

> > If only concern is the cost of change, why
> > not produce arguments for how to reduce that cost or to find a way
> > forward?
>
> Well that is easy. Don't perform change which has not been justified.

But it is justified for many, AFAICT.

> When the change involved has impact to existing users, that impact needs
> to be justified. When the change modifies long standing behaviour, that
> modification needs to be justified.
>
> I also think it is poor form to basically tell me to come up with a
> better solution because I don't agree with the need for the change. Time
> would be better spent coming up with justification for the change rather
> than criticise me for not agreeing with you.

What I find problematic here is that this is change would be a simplest
breaking change as possible, and we should try to get better at handling
these as there will be bigger ones, and we can't avoid them all the time.

I didn't intend to adress you directly if that is how it came out, but
this is a pattern I see a lot and wanted to express my opinion on it.
Thanks for giving a detailed response.