Eli Zaretskii <e...@gnu.org> writes: >> From: Andy Wingo <wi...@pobox.com> >> Cc: l...@gnu.org (Ludovic Courtès), guile-user@gnu.org >> Date: Thu, 09 Mar 2017 20:56:09 +0100 >> >> > That's what I'm trying to tell you: there's no aggression. >> >> I understand that different people can have different reactions and it's >> great that you can look through "style" to the substance. I and a >> number of other contributors (evidently including Ludovic) find it hard >> to do so, and the only reason we try is because we care about Guile. >> It's really weird though to try to ignore this "style" when the style >> often says precisely that we _don't_ care, in those words, and other >> times in as many words. > > Given the certain amount of frustration over the real problems that > didn't get solved until now, you can understand that, don't you? > > I had my share of problems reported here, mostly with working patches, > some of which took many moons, sometimes years to get solved upstream. > So I think I understand some of David's frustration, although the > problems I reported were nowhere near the gravity of those Lilypond > has. > > So maybe the project leadership should try to improve the efficiency > of handling bug reports and of catering to the problems raised by > projects using Guile, as a means to lower frustration and make the > environment friendlier?
The "project leadership" in Free Software more often than not does not have any assignable resources so there is little point in venting frustration in that regard. My concerns are not as much about lack of progress but rather about moving Guile in a direction where it becomes increasingly unfeasible as an extension language not just for LilyPond because extensive interaction with other programming models and languages becomes too expensive, invasive, fragile and inflexible. To a certain degree one can chalk this off as "growing pains" that long-standing users have to shoulder, at least when working with development rather than stable versions. But without a visible intent of actually prioritizing or even addressing those, you end up with more like a "one step forward, two steps back" approach rather than the other way round, at least for already established uses rather than those for which the steps forward are explicitly intended. LilyPond is getting removed from distributions these days because it requires Guile-1.8. Probably even worse, some distributions deliver binaries linked with Guile-2.0 (the options available for compiling with Guile-2.0 support are only intended for developers) which means that the binaries are not usable for serious work (far too slow and unstable). This situation has been developing for a number of years. It would probably take less effort to address to a tolerable degree than making Emacs-on-Guile more than an academic option. And make no mistake: there is quite an overlap in problems that need solving for making Emacs-Guile2 viable and making LilyPond-Guile2 viable. But Emacs does not suffer the same amount of migration pressure since there is no independent Elisp project in different iterations involved. It can just stick with what works, short of a political decision (like the one that put MULE into Emacs 20, costly then, amortized by now). -- David Kastrup
