bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-autogen] test failure with guile-2.0.2


From: Thien-Thi Nguyen
Subject: Re: [Bug-autogen] test failure with guile-2.0.2
Date: Fri, 15 Jul 2011 18:25:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

() Thien-Thi Nguyen <address@hidden>
() Wed, 13 Jul 2011 17:01:17 +0200

   Try to jump up and see things from a perspective that includes the motion
   of the people who follow the leader.  That will make you a better leader.

A little bird had two things to say to me:
- that was a pretty wise-ass way to say things (w/ emphasis on ASS);
- what makes you an expert at being a leader?

To the first, i guess everyone is entitled to their preferred analogy.
Perhaps a better blend might have been to take the recent post by Andy wrt
lambda tribalism and draw the analogy between the benefits of functional style
programming and functional style interface design, or rather the latent woe
associated with their non-functional practice.  In this case, "semantics
changed while name unchanged" is basically a big fat ‘set!’ to the libguile
API.  Reasoning and optimizations are out the window because the trust is
broken.  We revert to coping behaviors and ugly gnashing (e.g., Guile-BAUX).

But i didn't have the energy to say that then, and this brings me to the
second answer: i am no expert at being a leader, but i know regret when i feel
it.  I feel regret now for not finding the energy then, but i also felt regret
then, as a feeling i would not wish upon Andy in the future, with the ‘set!’
fanout growing ever larger, with long-time Guile users dying a little inside
at every thought of balancing new-and-shiny cool w/ new-and-shiny pain, with
that soreness manifesting in mostly-offtopic threads, etc, etc.  That way lies
dissipation.

It doesn't need to be that way if with functional style interface design, but
of course, w/ more bindings, the burden of unfettered generation can indeed
weigh heavy.  Hopefully, this serves to push back onto the designer the need
to really think things through, to account for continuity and compatability in
the quest for new functionality.  I suppose the trick is to use the regret you
know you will feel to fuel the intensity of the design process, kind of like
consciously structuring code to avoid ‘set!’.

To get back on-topic, since the change was relatively recent, one way forward
would be to revert it and redesign.  We could simply say "ok, that was a
mistake, please avoid Guile 2.0.[01] (or whatever), sorry we will be more
careful in the future".  The other way is to do as Bruce suggests, add another
interface element.  To me, the former takes some chutzpah but is preferable
anyway -- it shows a balance of strength and gentleness, not to mention regret.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]