On Tue, May 29, 2012 at 1:04 PM, David Kastrup <d...@gnu.org> wrote: >>> Bad input tends to let LilyPond segfault. You need C++ for that: it >>> is not possible in Scheme alone. Take a look at listener.cc, one of >>> our simplest C++ classes with things like >> >> From a user perspective, there is little difference in getting a >> Scheme level stacktrace or a segmentation fault. (I am assuming he is >> not doing any scheme hacking). By itself, exchanging core dumps for >> scheme stack traces is not that valuable. > > From a developer perspective, it is. > >> While the scheme integration have been a big leap forward in terms of >> expandability and flexibility, I think it has also been our gravest >> design error. Both for technical reasons (GUILE is a poor >> implementation), but also for practical reasons: writing scheme is >> hard for the general public, and it has surely decreased the amount of >> developer participation we've had. > > Writing C++ code is not possible for the general public since it means > recompiling matters. Do you really want to suggest that people would be > fine with writing C++ for every situation where now Scheme is being > used?
There are two separate discussions here: - how do we offer to average user a way to extend the program. I agree that C++ is not the way to go - how do we offer developers an environment to extend LilyPond, were extensions go back into mainline; this is connected with getting more developers on LilyPond. I agree John Q. Public will not want to recompile lilypond. For long term extensions developers, there just are not that many lisp/scheme developers. I say this both as a software engineer at google (which is full of bright computer scientist, but not so much list/scheme hackers), and as a casual observer. Compare for example: http://stackoverflow.com/ : C++ tag 120k questions, Scheme+Lisp: 4k questions https://github.com/languages : C++ is not the top, but lisp/scheme don't even register on the graph. For people that already program, typically compiling lilypond will be a smaller hurdle than learning scheme. > The point is that adding new parts to the C++ parts is hard. Look at > the stuff people enjoy playing with Scheme engravers, and Scheme > engravers are an afterthought fitted inside of a C++ engraver only > so-so. We have several people suggesting Scheme solutions to problems > on the LilyPond user list. Would they suggest C++ solutions? Wouldn't > that be more of a problem than a solution? > > Scheme might not have been the optimal choice, but it beats not having > an interpretative layer, and our interpretative layer is still much more > limited than desirable. To me the question is where we should invest: having the interpretive layer be more rich (where it is already incredibly rich *and* incredibly obtuse), or having better fundamentals (page breaking, spacing, collisions etc..) -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
