The best example of the leaky abstraction problem I can think of right now are actually visual HTML editors. HTML is very complicated and follows a 'WYSIWYM' model similar to LaTeX, however the visual editors try to force this into a 'WYSIWYG' model which simply does not work, especially when responsive layouts are a factor, as what you see is inherently going to change. This tends to result in things breaking in unexpected ways, because the user is not aware of the mismatch. Plus these tools are usually only aware of a small subset of HTML, so if they are used in combination with hand written code things get broken as a result.
As David notes, I am talking about input layer not internals. The lilypond syntax appears to be an abstraction over an object oriented design, 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. 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. The learning manual spends most of it's time going into things that I have no use for, such as multiple staff arrangements. 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. Irish trad music is different from classical tradition in that the scores denote a simple 'outline' of a tune. How they are actually played tends to differ a great deal, including implicit 'lilt' or 'swung' rhythms and ornamentation and melodic variations that are added by the player, generally differently every single time they play a tune. Outside of teaching materials it is rare to notate articulations, slurs, or ornaments at all. Standard playing style often attempts to emulate numerous historical bagpipes by slurring everything by default, and using fingered articulations extensively. I suspect that ABCn hasn't defined the Larson symbols both because of the above, and because folk musicians often notate fingered articulations using grace notes. However this notation requires different interpretation from the usage of grace notes in classical theory, and as a result only works within the scope of a given tradition. It's also very open to misinterpretation if encountered by classically trained musicians. Calling these 'grace notes' is also misleading as they are used as articulations, basically interchangeably with tonguing. They exploit the limits of human perception by being extremely brief. When played well they are so brief that their absolute pitch is not perceived. In order to do this dependably special fingerings or techniques are used. Grey Larson's book recognises the mostly my last point, which lead to his notation system. On 18 April 2018 at 09:37, David Kastrup <d...@gnu.org> wrote: > Andrew Bernard <andrew.bern...@gmail.com> writes: > >> Hello Robert, >> >> Speaking as a programmer myself with over forty years of experience, >> and an advanced lilypond users, I can categorically assert that >> lilypond is not trying to be 'clever'. This is an utter >> misunderstanding. Lilypond is however trying to engrave music to the >> highest possible standard, and this is an immensely difficult >> programming proposition, hence the complexity under the hood, and the >> slight difficulties in the syntax. It's not meant to be simplistic or >> easy like ABC. > > I hate to waste a good defense, but you are talking about its internals > here and Robert was arguing about the input layer with me. Different > beasts. It's akin to discussing plain TeX vs LaTeX based on the quality > of the output. The point of LaTeX is to provide an input and > abstraction layer, the typesetting remains the job of TeX, the program. > Now LaTeX is indeed bleeding complexity when you poke it too hard. > > LilyPond's input language is intended to be expressive and convenient > but a whole lot of pain goes into assuring that it bleeds in concordance > with both reasonable and unreasonable expectations even when you poke it > too hard. > > As an example, compare the 2.19 version and interaction of of #{ ... #}, > $, and # with the 2.12 one. The current version is quite "cleverer", > going to large pains to make sure that closures, error messages and > whatnot reliably point to where you'd expect them to be. This is a much > more thorough layer than LaTeX provides around TeX, and yet people feel > much more comfortable using LaTeX than plain TeX. The LaTeX layers fall > apart when problems occur and you have to debug. LilyPond layers tend > to hold up even under debugging. > > Robert may be speaking from experience, but experience without actual > knowledge can win over knowledge only when that knowledge in return is > lacking significant amounts of experience. > > And I'd argue that dismissing my experience in designing, managing, > maintaining, and explaining complex systems as insignificant does not > likely make for the best fitting working hypothesis. > > -- > David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user