Darius Blasband <[EMAIL PROTECTED]> writes: > On the positive side, I guess - Nicolas might contradict me here -
Had you not written that, I would not have answered :-p > that Python would have enabled far more people to hack with > the internals., as the procedural-OO paradigm is more popular than > functional programming. Is Scheme really preventing users from hacking LilyPond's internals? I didn't write a single line of Scheme code before using lily (except in school). Just bookmark guile's reference manual and read the files in lilypond's scm/ directory. Its syntax is the simpliest, the names are intuitive (Scheme is said to be "cleaner" than Common Lisp in that respect), what else? (Please, no parentheses debate). > Besides, as far as I know, I would assume that Python provides enough > functional programming primitives for the cases where you truly needed > them. This is not really the point, as I'm not sure one can say that the Scheme parts are written in a "functionnal" style in LilyPond. There are side effects in some parts, some parts are OO, some parts have a more functionnal taste... It's clearly multi paradigm, which make me agree with Pedro: it looks like Common Lisp would have been more appropriate than Scheme. I often feel like reinventing the wheel when writing guile code (no LOOP, what a pain!). To dissipate some possible misconceptions: if Scheme is said to be a "functionnal" language, Common Lisp is certainly not only that. It is a multi-, or rather an omni-paradigm language. So "parentheses" does not imply "functionnal programming". Speaking of that: I've seen the "Alien lisp technology inside" logo at: http://lilypond.org/web/about/ This is rather a Common Lisp logo, the many eyes figuring the multi-paradigm caracteristic of Common Lisp; its author was also thinking about drawing a logo for Scheme, perhaps showing a mascot with "two (very well functionning) eyes". See http://www.lisperati.com/logo.html [EMAIL PROTECTED] (Pedro Kröger) writes: > I could sea the advantage of re-writing lily in only one language. but > this language would have to have a fast implementation and be dynamic > and very high-level. I can't think of a better choice than common > lisp ;-) Dans mes bras, ami ! :-) Nicolas _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user