You are largely missing the point I was trying to make, however I have a lot of work to do and cannot be bothered to argue.
On 18 April 2018 at 13:24, David Kastrup <d...@gnu.org> wrote: > Robert Hickman <robehick...@gmail.com> 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 lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user