Robert Hickman <[email protected]> writes: > The best example of the leaky abstraction problem I can think of right > now are actually visual HTML editors.
That's more in line of complaining about Denemo than LilyPond. Either way the solution lies in not confusing the editor's domain with the the result domain. > As David notes, I am talking about input layer not internals. The > lilypond syntax appears to be an abstraction over an object oriented > design, No, that definitely isn't it. Absolutely not. > with a lot of implicit 'magic', and for me as a new user it is very > difficult to see why it does some things, like randomly creating an > empty staff. What I'm wandering is weather it would be clearer to just > use an object oriented syntax directly and make the implicit stuff > explicit. LilyPond is designed as an input language. Its internal data structures are mostly mapped to Scheme data structures. Scheme is a functional language, not an object oriented language. Large swaths of LilyPond are coded in C++ for efficiency reasons, but the data models of C++ don't really have exposure worth noting to LilyPond. Understanding LilyPond's input is not related to understanding C++ and not significantly related to Scheme either. Its input language is defined in a traditional lexer/parser manner implemented with a standard LALR(1) parser generator. For debugging and programming reasons, its productions these days pass around Scheme data structures exclusively but that's a comparatively recent development. So no: you are completely wrong with your musings and they have absolutely no relation to internals of LilyPond: this rather concerns the completely independent syntax (and parser-internal semantics) of its input files. > ABC notation does most of what I need, but lacks a few minor > formatting controls and the ability to define symbols which I need to > finish the work that I'm doing. Lillypond seems vastly more > complicated than I need. If you don't insist into digging yourself into the complexity, you can get away perfectly well without it. But you refuse doing so because you express your a priori confidence that its authors and maintainers are incapable of properly layering its complexity. > The learning manual spends most of it's time going into things that I > have no use for, such as multiple staff arrangements. If you want to pay for a personal tutor catering to your personal needs, of course you can save the time skipping over unwanted material. Manuals are a compromise between saving time for the teacher and saving time for the learner. As we have a vastly larger number of users over teachers, they are freeing resources for the project. > Sheet music could either be complex or simple depending on what you > are trying to do, for what I'm doing a fixed-spacing 'dumb stacking > algorithm' that abcm2ps appears to use is perfectly adequate. So? What are you hoping to gain by lecturing everyone how bad LilyPond must have been designed according to your experience with and/or without it? I mean, I am the last one to let a good opportunity for pontificating go to waste, but so far I fail to see that you have availed yourself of such an opportunity. Perhaps try to figure out what you actually want to get achieved and then think of plans, technical and/or social, to actually get them done. There is no point playing to your strengths without applying them in a useful manner to problems you want to see solved. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
