Hi, Neil Jerram <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes: >> But I started really enjoying Scheme and wanting to write less C, more >> Scheme. So why bother writing C at all when I could avoid it? Well, >> for "performance reasons". > > Completely agreed so far, except that there is another reason for > writing C code: simply to interface with a C library that already > exists. There are a few of those out there. :-) Of course. But I mean: when you *could* avoid writing C, e.g., because you don't rely on any specific C library's features, it often occurs that you actually can't avoid writing C because of performance reasons. > 1. The fundamental premise of writing in a scripting language must be > that it is easier / quicker / more fun / more effective than > writing in C. Therefore one must want to maximize the amount of > scripting language code that one writes, compared to the C code. Agreed (although I'm not fond of the term "scripting language", since it conveys the idea that the language, not the implementation, is limited to a particular use case). > 2. I originally thought that a software-component-using-Guile should > typically be a complete application - such as Gnucash. Now I think > that a software-component-using-Guile should ideally be a library - > such as a module providing operations on financial objects - and > that applications should be created, in Scheme, through relatively > trivial composition of sophisticated libraries. Agreed. Still, as you compose more and more such libraries through Guile, you end up having more and more Scheme code, and (potentially) more and more performance concerns. :-) > It's difficult at this point to avoid a possibly unwelcome question: > what makes Guile Guile, and why wouldn't we be better off contributing > our resources to an implementation that already is faster? Indeed, that's a good question, although a tough one for someone that's too "emotionally involved" with Guile. ;-) To be honest, I don't know other implementations well enough to compare available features. I have the feeling that Guile's public (Scheme) API is pretty good and quite rich. We have POSIX multithreading, which not all implementations support; we have a nice module system (although it doesn't play well with macros ;-)), and of course a good and well-documented C API. Your new debugging infrastructure contributes to Guile's friendliness. Kevin's Guile-Lint is also an important contribution to Guile's usability IMO (it deserves more advertisement). It seems that we also have a set of nice libraries/bindings in a variety of domains. > The kinds of things that I am most interested in are: > > - finishing off the debugging infrastructure > > - progressive completion and polishing of the manuals > > - improving tracking, provision and regression testing of the > available Guile add-on libraries; also providing interesting > examples of how interesting things can be achieved by combining such > libraries > > - possibly integrating with other systems' library repositories (such > as Snow) > > - in general, any kind of situation where we can create value just by > putting existing stuff together (another possible example: the Emacs > Lisp translation support + existing Emacs Lisp libraries), or by > better tracking of what's available. These are interesting and important goals. I'm not sure about the last item, though, being unfamiliar with Emacs Lisp support in Guile. > The phrase "what we'd like to see" is IMO unrealistic, though. I > don't think any of us (Guile developers) can commit to achieving > particular things by particular dates, and I wouldn't wait to delay a > new release, once a sufficient amount of interesting new stuff has > accumulated, because a particular target has not been met. Of course we can't commit to anything. Still, it's good if each of us can say what he'd like to work on in HEAD, and get feedback from others. It helps find motivation, too. So far, I think we just hadn't discussed any plan for 1.9. So it's good we've opened the debate. :-) Thanks, Ludovic. _______________________________________________ Guile-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/guile-devel
