Re: [PATCH] Fix the R6RS exact-integer-sqrt and import into core guile

[Detlev Zundel]

Hi Mark,

[...]

> Sometimes there's no good reason to use C, but it's simply due to a
> developer's personal preference.  Maybe they don't have much experience
> writing Scheme and are much more comfortable in C.  Maybe they already
> had this big pile of C code before they learned to love Scheme.  Maybe
> they're part of a larger team, most of whom either don't know Scheme or
> are unwilling to use Scheme for the main project, but they want to add
> user extensibility and chose Guile.  Since they already have libguile,
> they might as well use its arithmetic functions in a few places to
> improve robustness against overflows.
>
> We cannot force people to use Scheme.  If we wish for libguile to be
> attractive for use by projects primarily written in C, we ought to
> extinguish this unfortunate recent tendency to say "people ought to be
> writing Scheme not C", and we ought to stop using that as an excuse to
> block improvements to the C interface.

Although I'm more a passive observer on this mailing list, I still want
to add a little bit to this discussion.  Personally I very much embrace
and support this "write Scheme rather than C" stance being taken by some
of the project maintainers.

Although it is an obvious truth, it helps to remember that no project
can serve all wishes of each and every developer.  As a consequence it
is clear that a project has to make a choice of direction of where it
wants to _lead_.  This direction should of course reflect the needs of
the project itself, i.e. maintainability, testability, documentability,
etc.

One should also be aware that the APIs offered can severly influence
people in their own designs.  Let's face it, most developers (including
myself) are rather lazy and try to do as little changes as possible
_even_ if larger changes would be _positive_ for the work as such.  A
project _can_ (and I'd say should) force people at least to think about
such changes by publicly offering more clean abstractions.  A project
can surely transport a message to new users this way.

And please, let us not try to consider theoretical needs of potential
guile users but rather concentrate on the needs of the guile maintainers
and current users.  The time to discuss things which can negatively
influence maintainability and testability is the time when an actual
potential user comes along, not earlier.

As a side example, think of how the Linux kernel would have dissolved to
be an unmaintainable nightmare if every system call suggested on the
mailing list would have been adopted.  A project is well advised _not_
to follow each and every cry of every developer.  That's because crying
is easy, but maintaining ain't ;)

Ok so much for my "bystander view".  Thanks for listening.
  Detlev

-- 
These days, even the most pure and abstract mathematics is in danger
to be applied.