Iterative Tinkering depends on API stability

Iterative Tinkering depends on API stability

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]

Hi,


Sacha Chua writes how she tinkers incrementally, finding time between
tasks, asking “What's the smallest step I can take? What can I fit in
15-30 minutes?” — Choosing what to hack on:
https://sachachua.com/blog/2024/01/choosing-what-to-hack-on/

This approach improves the work environment step by step to become
better than any other. In a similar way, I now ended up using exwm, and
while not perfect, it just works better for me than all other systems.

But since this depends on doing small steps and moving forwards in
little steps, there’s no time for large-scale maintenance. You define
what’s the right step, and then you take it.

If something breaks, that takes up at least a full improvement slot.
Often just searching for a solution takes longer than you have.


So this approach — which can lead to the best personal work environment
possible — depends critically on API stability. Even a deprecation that
affects multiple of your modifications can put a stop on tinkering for a
long time, because fixing something that broke due to changes from
someone else is a very different kind of working than letting your
curiosity lead to even out a rough edge in your workflows.


Someone would surely come in and quote xkcd 1172: https://xkcd.com/1172/
I consider that a harmful strip — it has a point, but it got weaponized
to brush away concerns about stability and muddies up the understanding
that those with the most complex or most advanced setup are the ones
most likely hit by API breakages.

If you see 1172, remember that Lilypond had almost ended up ditching
Guile because of breakage that hit them with the 2.0 release. The one
Guile-using tool that is absolutely dominant in its domain (the most
beautiful music scribe) had almost stopped using Guile.

For Emacs, the impact is even bigger, because far more people tinker to
optimize their setup.


And recently I’ve seen more breakage in Emacs.

For example my address completion in mu4e broke a week ago. I don’t have
time or energy to fix it. And mu4e started to send emails to myself if I
answer my own message in a thread with someone else, because the R
shortcut no longer sends wide replies (W shortcut). And there’s a risk
that it will stay broken: storing each address I send emails to in mu4e
automatically has been broken for years. It took me months before I got
to fix my org-mode setup when it suddenly started indenting lines while
typing. That actually affected me live while giving parts of a lecture
interactively.


So I want to plead to remember the risk of volatile software¹, volatile
infrastructure², and soft trauma³, when taking decisions about backwards
compatibility.
Breaking backwards compatibility has much wider-ranging implications
than it seems while working on code, and it hits the most most
advanced specialist tooling and the most enthusiastic tinkerers the
worst.


¹ Volatile Software — do not be the tool which breaks itself or other
  tools on update.
  https://stevelosh.com/blog/2012/04/volatile-software/

² Volatile Infrastructure is worse than volatile applications.
  https://www.draketo.de/software/volatile-infrastructure


³ Software developers should avoid traumatic changes — two kinds of
  trauma: everything needs work to get working again or to get idiomatic
  again.
  https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html


Best wishes,
Arne

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Iterative Tinkering depends on API stability

[Eli Zaretskii]

> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Date: Wed, 15 May 2024 07:34:20 +0200
> 
> So I want to plead to remember the risk of volatile software¹, volatile
> infrastructure², and soft trauma³, when taking decisions about backwards
> compatibility.
> Breaking backwards compatibility has much wider-ranging implications
> than it seems while working on code, and it hits the most most
> advanced specialist tooling and the most enthusiastic tinkerers the
> worst.

I think you are preaching to the choir here.  Breaking backward
compatibility is something we try to avoid like the proverbial plague,
every single day.  The example you mention, with mu4e, is not
necessarily relevant to this list, since mu4e is not part of Emacs;
you should bring that problem to the attention of the mu4e developers.

Re: Iterative Tinkering depends on API stability

[Emanuel Berg]

Eli Zaretskii wrote:

> I think you are preaching to the choir here.
> Breaking backward compatibility is something we try to avoid
> like the proverbial plague, every single day. The example
> you mention, with mu4e, is not necessarily relevant to this
> list, since mu4e is not part of Emacs; you should bring that
> problem to the attention of the mu4e developers.

There was a new standard for C which arrived at some point in
time, and it was quite amusing since the only thing it seemed
to be concerned with was not breaking the previous standard :)

-- 
underground experts united
https://dataswamp.org/~incal

Re: Iterative Tinkering depends on API stability

[Tassilo Horn]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

Hi Arne,

> And mu4e started to send emails to myself if I answer my own message
> in a thread with someone else, because the R shortcut no longer sends
> wide replies (W shortcut).

Yes, I was affected, too, and sent a lot of replies to only the author
instead to mailinglist and author.  That's how I cope with it now:

--8<---------------cut here---------------start------------->8---
;; I keep on sending replies (R) instead of wide replies (W), so better
;; make R ask if I'm really sure.
(advice-add #'mu4e-compose-reply
            :filter-args
            (lambda (f &optional wide)
              (list (or wide (yes-or-no-p "Wide reply? "))))
            '((name "Ask if we actually want a wide reply (Reply All).")))
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: Iterative Tinkering depends on API stability

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

Hi Tassilo,

Tassilo Horn <tsdh@gnu.org> writes:

> Yes, I was affected, too, and sent a lot of replies to only the author
> instead to mailinglist and author.  That's how I cope with it now:
>
> --8<---------------cut here---------------start------------->8---
> ;; I keep on sending replies (R) instead of wide replies (W), so better
> ;; make R ask if I'm really sure.
> (advice-add #'mu4e-compose-reply
>             :filter-args
>             (lambda (f &optional wide)
>               (list (or wide (yes-or-no-p "Wide reply? "))))
>             '((name "Ask if we actually want a wide reply (Reply All).")))
> --8<---------------cut here---------------end--------------->8---

Thank you!

This also triggers when I use the W shortcut — though from the code I
don’t understand why.

I shortened the question to y-or-n-p so I only have to type y.

Best wishes,
Arne

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Iterative Tinkering depends on API stability

[Tassilo Horn]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> This also triggers when I use the W shortcut — though from the code I
> don’t understand why.

Oh, because there was a bug in the advice function which I didn't find
because I never use W.  Here's a corrected version:

--8<---------------cut here---------------start------------->8---
  ;; I keep on sending replies (R) instead of wide replies (W), so
  ;; better make R ask if I'm really sure.
  (defun th/mu4e-compose-reply-filter-args (args)
    "Ask if we actually want a wide reply (Reply All)."
    (list (or (car args) ;; the first arg is `wide'.
              (yes-or-no-p "Wide reply? "))))
  (advice-add #'mu4e-compose-reply
              :filter-args
              #'th/mu4e-compose-reply-filter-args)
--8<---------------cut here---------------end--------------->8---

> I shortened the question to y-or-n-p so I only have to type y.

I use (setq use-short-answers t) so that every yes-or-no-p becomes a
y-or-n-p.

Bye,
Tassilo

Re: Iterative Tinkering depends on API stability

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

Tassilo Horn <tsdh@gnu.org> writes:

> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>> This also triggers when I use the W shortcut — though from the code I
>> don’t understand why.
>
> Oh, because there was a bug in the advice function which I didn't find
> because I never use W.  Here's a corrected version:

Thank you!

Best wishes,
Arne

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]