This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: NIMP thing


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> While I of course share your goals concerning Guile and Guile code
> (and prefer coding over discussing), we obviously completely disagree
> regarding the approach of your change.  [It is this approach which I
> call "careless".  Made by a less careful programmer it would have led
> to a larger mess.]
> 
> It's not that I'm complaining about it.  I think it's plain wrong and
> should be taken out.  (This is the first main message of this letter.)

What's the antecedent of "it"?  The approach or the change?  I'm
absolutely positively certain of the change.  The approach was a
judgment call that involved tradeoffs of my time and my estimation of my 
abilities to make the entire change in one fell swoop.  I stand by that
decision, but recognize that the variables compute differently for
others. 

> The purpose of my "alarm signal" and the following discussion was to
> get you to revert the NIMP changes and do it in a safer and more
> controlled way.  Yes, that would have taken valuable time, but we are
> now dealing with very high values: Guile efficiency and Guile
> stability.

Until someone demonstrates that guile is slower somewhere, I put *no*
stock in the efficiency argument.  I've demonstrated undeniably that for
a prominent platform with the standard compiler there is zero difference
in the common case where performance could've suffered.  Period.

The stability argument is a real issue, but bugs are just bugs and the
class of bugs that this change may have introduced is easy to fix.
(Finding them maybe harder, but again I re-iterate that I likely fixed
more bugs than I introduced, and the bugs that I introduced will likely
be easier to find than the ones that I fixed [the opposite side of that
is that they will be bugs that *need* to be fixed because they will be
found]).

<snip>

> However, I've now concluded that you won't revert your changes, and,
> given that I have allegedly quit as Guile developer, and given both of
> our time constraints, I can't force you to do it.  So, I'll now quit
> pushing for it.  (This is the second main message.)

Good; now let's get on with adding regression tests to gain confidence
in the stability of Guile and docstrings to get Guile's reference manual 
up to speed!

> Just, finally, I'm _not_ trying to attack you.  I'm attacking your
> approach.  I even think your approach can be good, but not for the
> _infrastructure_ of Guile.  I appreciate you, but not the particular
> approach in this particular case (= NIMP thing).

Fair enough;  and if someone had supported the more conservative
approach in the two days of discussion before I made the change, I'd've
probably gone that route;  as I mentioned, I considered it but decided
it wasn't too hard to get right so it would be better to just do it all
in one fell swoop.  I almost definitely would've pushed hard for the
conservative approach if anyone else was suggesting the change;
hopefully my ego and my abilities aren't at too much of a mismatch
here. 

> But, given your skill as programmer and your general intelligence,
> let's hope that you are right in your beliefs about Guile code and
> compiler optimizer abilities, and that there hasn't been many serious
> bugs introduced.  (I'm actually prepared to expect that this
> (sunshine) is the case.)

Me too... though I'm taking the 101 pages of diffs from dec-15 to dec-17 
home to double check and try to ensure sunshine;  years of experience
have taught me that this is a great way to find bugs (although I know
it's better if someone *else* looks at the diffs;  I want to *not* find
problems, but others really want *to* find mistakes).

> And, I promise to start the same kind of discussion next time you
> touch the infrastructure with the same methodology.
> (Do I need to say that this was the third one?  ;-)

Well, if I had to do it over again, I'd do it the other way;  people's
confidence in their interpreter is incredibly important and the
conservative approach might've avoided these questions and doubts.

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]