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,

If there is anyone at fault here, it's me; I should have encouraged
Greg to take a more conservative approach to making this change when
he first brought it up as a suggestion, however, my attention was
somewhat distracted

Programmers always want to "just do it" and as maintainer it should
be my job to sometimes push back a bit and encourage people to be
more careful.

However, now that the change has been made, I believe Greg has
reasonably demonstrated that there was no significant impact on
performance and stability. Given this, I don't think it would
be fair to ask him to revert his change unless someone can
provide a concrete reason to believe there is a problem with
it. I haven't read all of my email yet, but I haven't yet seen
eivdence to support this proposition.

Nonetheless, we should be much more careful with infrastructure-level
changes in the future. We should discuss them and look at
profiling data and regression tests before and after.

I appreciate everyone's desire to move things forward and get results,
but Guile is becoming widely enough used that sometimes we need to
take things a bit slower to ensure continued performance and stability.

Perhaps in some cases this means waiting a bit to give others a chance
to comment before making infrastructural changes.

in any case, I will try to be more attentive about these kinds of
changes.

 - Maciej

Mikael Djurfeldt wrote:
> 
> 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.)
> 
> 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.
> 
> I also believe that it is possible to make Guile more available to
> hacking, and think it's a good intention to lower the threshold for
> hacking.  But I believe strongly that one should use different
> approach to hacking some particular feature of Guile and hacking the
> infrastructure of an interpreter which has been stable for years.  I
> believe there exists such safer approaches (Marius gave a concrete
> suggestion) that would perhaps take longer time to implement, but
> which would lead to the same good goals and which wouldn't endanger
> efficiency and stability.
> 
> 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.)
> 
> 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).
> 
> 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.)
> 
> 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?  ;-)
> 
> /mdj

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