Re: Default lexical-binding to t

[Psionic K]

Apologies for jumping in at the end to represent a view.

+1 lexical binding default.  It's a fact that users need to learn but
does not contribute to their goal of writing a package.  The context
for the conversation is lost.  It is not like compiled versus
interpreted or functional versus declarative or any number of other
trade-offs that have a strong presence in modern programming
conversation.  Dynamic scope likely requires explaining to people with
ten years of experience.  The likely result of that explanation is a
deep mistrust of the ecosystem.  It has become a red flag.

The reason I'm commenting is because the conversation intersects with
more general topics like velocity, ecosystem strength, entitlement,
and the correct thing to do as an engineer.

Users who wish to use Emacs without any disruptive changes whatsoever
always have a valid choice:  don't upgrade.  Most routes to obtaining
Emacs provide several old versions.  People who upgrade their OS and
Emacs *want* change and have opted into it.  If a user stumbles into
an upgrade and decides they are not ready, they may downgrade.  This
is not at all callous or dismissive.  It is the correct social
contract in an ecosystem powered by opt-in cooperation and individual
incentive motivating our interdependence.

Not upgrading blindly and taking responsibility when upgrading are
well precedented expectations in other software where backwards
compatibility and system uptime are primary considerations, such as
kubernetes.  People in that ecosystem maintain good news files and
upgrade instructions.  They deprecate things patiently and with
warnings.  But they do deprecate.  When a change is recognized as
beneficial to a modest fraction of active users, it is rapidly
introduced and marked as experimental before being stabilized or
discarded.  All of these stability transitions are in the news file.
That is a sufficiently strong contract with users, whether for
commercial or non-liable use cases.  It is a good standard of mutual
respect among engineers.

When we talk about users who contribute to ecosystem strength, there
is no such thing as a user who consumes Elisp off of the wiki and
demands both upgrading Emacs yet never being exposed to changes in
Emacs.  This kind of user may exist, but they are detached from the
ecosystem, detached from the interdependence and cooperative benefit.
Our individual incentive to participate in cooperative software
development only exists through change, through new feature
development and adoption.  There is no cooperative benefit if there is
no change.  If there is no change, there is no incentive to cooperate
and then no cooperation.

That is important because Emacs has been sprouting features against a
backdrop of tree sitter and LSP relieving the "editor" from a variety
of specific responsibilities in exchange for more general ones.  Those
changes came with greater garbage production, need for native
integration, and greater processing load.  I expect we are only going
in the direction of greater, not less dependence, driven by demand for
semantic search, translation, and "gray" automation tasks such as
linting for business rule violations described in natural language.
As a package author, even if I write a package to handle simple
bindings and editing commands in 2025 it looks nothing like one in
2015, and the source of demand is external.  The demand for velocity
is unavoidably increasing, not decreasing.

The interests (not rights) of users who do not want change are always
easily protected.  They are not dependent and do not benefit from
cooperation.  They simply should not upgrade.  The interests of users
who are interdependent and are incentivized to cooperate are the
correct and only properly aligned interests to consider.  When the
latter are compromised for the sake of the former, those who cooperate
are having their interests sacrificed to those who do not.  There may
be users who wish for Emacs to follow them into retirement and even to
the grave, and Emacs 30 is a great choice for them.  I respect that
they act according to their individual interests.  Not all of us have
this luxury, and only the people with cooperative incentive should be
considered when estimating cooperative benefit.  The dynamic part of
the ecosystem must take care of itself, first, always.

The other points about spending minor effort to save people time on
upgrades are completely valid.  However, after making "best effort" to
do things right, it's okay to break some unmaintained init file of a
user who only ever shows up to complain on the mailing list and then
tell them to downgrade.