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

[Tim Cross]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org> writes:

> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00794.html
>> ...
>> At the end of the day, this seems like a non-problem driven by a
>> belief/ideology that mixing user and auto-generated code is so wrong it
>> has to be eliminated. If there was evidence of significant adverse
>> impact to users due to this practice, change would be warranted.
>> However, as it now stands, I cannot see how such change can be
>> justified.
>
> 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?

> 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.
>
> How about split of early-init/creation
> of straight.el? 

iWhat about it? How is it relevant to this proposed change?

> 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. 

>  
> 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.

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.