Roadmap to lily code

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap to lily code

Pedro Kröger
Han-Wen Nienhuys <[hidden email]> writes:

> I'm also not sure it's a good idea. If you want python, it would be
> better to start afresh with a python version of LilyPond, and move
> speed-critical things to C(++). Then, end-result will be more
> "pythonic"

> I imagine that the end result will be slower than the current
> GUILE/Scheme combo.

I bet it will be, unless lots of things will be written in C(++). I
can't see the advantage of doing that: re-write something that is
already working in c++/guile to c++/python.

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 ;-)

Cheers,

Pedro Kröger


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Pythonization (was Re: Roadmap to lily code)

andrea valle
In reply to this post by Han-Wen Nienhuys
(Could be of some interest so I keep it on the list)

> I'm also not sure it's a good idea. If you want python, it would be
> better to start afresh with a python version of LilyPond, and move
> speed-critical things to C(++). Then, end-result will be more
> "pythonic"
>

And in that case? Could you make a rough estimation? Is it feasible or
is it (as a matter of facts) science fiction?

> I imagine that the end result will be slower than the current
> GUILE/Scheme combo.
My coding time is precious than machine's working one:)

-a-


>
> --
>  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen
>
>
Andrea Valle
DAMS - Facoltà di Scienze della Formazione
Università degli Studi di Torino
[hidden email]



_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap to lily code

Cameron Horsburgh
In reply to this post by Mehmet Okonsar-3

Christian Ebert wrote:

> * Han-Wen Nienhuys on Thursday, December 08, 2005:
>
>>andrea valle wrote:
>>
>>>How much for a migration to python as a sponsored feature :-)?
>>
>>5 digits.
>
>
> 10000 cent is a bit cheap ;-)
>
> c

10000 c? No, he meant one whole hand. That's still cheap, because I
expected at least an arm and a leg.

;-)

Cameron



_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap to lily code

Donald Axel
In reply to this post by Pedro Kröger
On Thu, 08 Dec 2005 12:00:50 -0200
Pedro wrote:

> 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 ;-)

If it's not a sarcasm then you must be a nice creative person to
ask: how did you learn Lisp? I guess you weren't interested in
string-handling? Or is there a CommonLisp "substring" function?

How do you "think" (invent, construct) control-flow if Scheme (and
Lisp?) uses only tail-recursion as a flow-control mechanism?


/Thanks in advance from Donald

--
dax2-tele2adsl:dk -- http://d-axel.dk/  Donald Axel


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap to lily code

Pedro Kröger
dax2 <[hidden email]> writes:

> how did you learn Lisp?

1. reading books like SICP [1], PCL [2], PAIP [3], ANSI Common Lisp [4]
   and others

2. reading articles like Paul Graham's to "get" the language

3. writing code

4. reading other people code

5. asking questions (e.g. on comp.lang.lisp)

> I guess you weren't interested in string-handling? Or is there a
> CommonLisp "substring" function?

of course it is (subseq). you may want to check this link [5]. if you
need something more powerful there is a regular expression package as
well [6]

> How do you "think" (invent, construct) control-flow if Scheme (and
> Lisp?) uses only tail-recursion as a flow-control mechanism?

you have to keep in mind that while the scheme standard is very small,
many implementations have more stuff built-in.

OTOH, Common Lisp is a very big language with all sorts of control
mechanisms like dolist, do, dotimes, loop, and much more [7]. a very
flexible condition system (other languages have only "Exception
Handling") and a very powerful object system. All defined in the ANSI
standard. Check the standard and see for yourself [8] :-)

> /Thanks in advance from Donald

You're welcome

Cheers,

Pedro Kröger

Footnotes:
[1] http://mitpress.mit.edu/sicp/full-text/book/book.html

[2] http://www.gigamonkeys.com/book/

[3] http://www.norvig.com/paip.html

[4] http://www.paulgraham.com/acl.html

[5] http://cl-cookbook.sourceforge.net/strings.html

[6] http://www.weitz.de/cl-ppcre/

[7] http://www.lisp.org/HyperSpec/Body/sec_the_data__w_dictionary.html

[8] http://www.lisp.org/HyperSpec/FrontMatter/Chapter-Index.html



_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap to lily code

Pedro Kröger
In reply to this post by Donald Axel
dax2 <[hidden email]> writes:

> how did you learn Lisp?

1. reading books like SICP [1], PCL [2], PAIP [3], ANSI Common Lisp [4]
   and others

2. reading articles like Paul Graham's to "get" the language

3. writing code

4. reading other people code

5. asking questions (e.g. on comp.lang.lisp)

> I guess you weren't interested in string-handling? Or is there a
> CommonLisp "substring" function?

of course it is (subseq). you may want to check this link [5]. if you
need something more powerful there is a regular expression package as
well [6]

> How do you "think" (invent, construct) control-flow if Scheme (and
> Lisp?) uses only tail-recursion as a flow-control mechanism?

you have to keep in mind that while the scheme standard is very small,
many implementations have more stuff built-in.

OTOH, Common Lisp is a very big language with all sorts of control
mechanisms like dolist, do, dotimes, loop, and much more [7]. a very
flexible condition system (other languages have only "Exception
Handling") and a very powerful object system. All defined in the ANSI
standard. Check the standard and see for yourself [8] :-)

> /Thanks in advance from Donald

You're welcome

Cheers,

Pedro Kröger

Footnotes:
[1] http://mitpress.mit.edu/sicp/full-text/book/book.html

[2] http://www.gigamonkeys.com/book/

[3] http://www.norvig.com/paip.html

[4] http://www.paulgraham.com/acl.html

[5] http://cl-cookbook.sourceforge.net/strings.html

[6] http://www.weitz.de/cl-ppcre/

[7] http://www.lisp.org/HyperSpec/Body/sec_the_data__w_dictionary.html

[8] http://www.lisp.org/HyperSpec/FrontMatter/Chapter-Index.html



_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap to lily code

Nicolas Sceaux
In reply to this post by Darius Blasband

Darius Blasband <[hidden email]> 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

[hidden email] (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
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap to lily code

Darius Blasband
I would have never thought that this mailing list, of all places,
would host yet another language war !

Quoting Nicolas Sceaux <[hidden email]>:

> > 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 sure believe it does. Scheme is ok, but too remote to many people's
culture. My perception has always been that the first few hurdles
were just to high for comfort, and that people who might have been
tempted to do things just did not because getting their first piece
of Scheme to work took ages. This was so frustrating (to me, at least)
that in due time I suggested we'd organize some kind of workshop to address
this first few hurdles issue.

I don't even try to suggest that Python (or Perl, or whatever...)
is better in abstract or purely scientific terms. As a matter
of fact, I'm no big Python fan myself. However, evidence seems
to show that extensible systems based on Python, Lua, or Tcl are more
often and proficiently extended than systems based on Scheme - Lilypond
being a fair example of this.
I
Well, as in most language issues, I don't expect to change anyone's mind
anyway :-)

Darius.





_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap to lily code

Han-Wen Nienhuys
[hidden email] wrote:

>>Is Scheme really preventing users from hacking LilyPond's internals?
>
>
> I sure believe it does. Scheme is ok, but too remote to many people's
> culture. My perception has always been that the first few hurdles

Scheme doesn't really help, but I doubt whether this is the real reason.
For example, Darcs (a distributed Version control system) is written in
Haskell, a language which is arguably just as or more obscure than
Scheme. In its short life (approx. 2.5 years), it has attracted a number
of contributors, to the point that 50 % of the code (IIRC) is now coming
from the other people than the project leader.

I think that Scheme is the smallest problem in getting more LilyPond
contributors.

Larger problems are:

  * a user base largely consisting of musicians (ie. non-hackers)

  * music typesetting, which is as much of a esoteric niche problem as
you can get.

  * An architecture that only has started stabilizing only now (I'm
finally satisfied with the architecture of the Grob engine now, I think)

> I don't even try to suggest that Python (or Perl, or whatever...)
> is better in abstract or purely scientific terms. As a matter
> of fact, I'm no big Python fan myself. However, evidence seems
> to show that extensible systems based on Python, Lua, or Tcl are more

Examples?  In most extensible "user" applications, there is a big
barrier to extending the application, because the learning curve is
steep, and knowledge of the user-interface of an app doesn't necessarily
help with programming it.

Case in point: as a die-hard Emacs user, I still don't know how to write
Elisp.

--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap to lily code

Pedro Kröger
In reply to this post by Darius Blasband
[hidden email] writes:

> I would have never thought that this mailing list, of all places,
> would host yet another language war !

It was not my intention to start a language war. I should have made
clear that my point was:

1. I don't see the point of re-writing working code just to replace a
   language (scheme in this case) and end up with the same estructure of
   c++/<the-new-language-here>. I'd see the benefit of rewriting the
   whole thing to get rid of c++, having only one (high-level) language
   in the end.

2. The main reason I mentioned Common Lisp was because it would be much
   easier to convert a code from scheme to CL than to haskell, for
   instance. And I do believe that CL would be more apropriate and
   faster to be used as the only language than scheme

of course I think that CL is good for other reasons, but I shall not
mention here because I don't want to start a war :-)

> However, evidence seems to show that extensible systems based on
> Python, Lua, or Tcl are more often and proficiently extended than
> systems based on Scheme.

I respectfully disagree, Emacs is an example of a program who uses a
lisp dialect (not scheme) and has a *huge* amount of contribution. Even
from people who have nothing to do with lisp (e.g. java programers).

Pedro Kröger


_______________________________________________
lilypond-user mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-user
12