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.
