Janek Warchoł <janek.lilyp...@gmail.com> writes: > On Wed, Sep 26, 2012 at 9:52 AM, David Kastrup <d...@gnu.org> wrote: >> Janek Warchoł <janek.lilyp...@gmail.com> writes: >>> Currently we want to focus on syntax alone. >> >> If all you have is a hammer, every problem looks like a nail. >> >> "Hard to do" is a large problem class, and it is not necessarily clear >> to users which problems could be diminuished by syntax changes, which >> are accessible nicely with the existing syntax, and which would warrant >> different mechanisms and frameworks. > > Sorry, i should've used the term "ly language". What i mean: when > asking users about their problems, i wouldn't differentiate between > these two areas - i'd just ask for everythin. It would be our job to > decide what could be done with a bit of syntactic sugar, and what > needs changes in mechanisms and frameworks. > In other words, i'd just ask users for "things that need a change in > ly language", where "a change in ly language" can be either a helper > function or an actual change in how things work internally... I hope > that's clear. > (and it seems that we agree after all)
Not sure. To get back at the hammer analogy, users might ask for a heavier hammer if they have problems getting screws in place. Or for a more convenient way to enter/express xxx when they should not be required to bother with xxx at all. >> The text-based input of LilyPond makes it orders of magnitude better >> for swapping home-made recipes than WYSIWYG systems, but we should >> not lose sight of the value of tweak-free black-box solutions over >> that. The idea with a black-box approach is not necessarily that you >> _can't_ open the box and look inside, but that you in general don't >> need to do so. > > Do i understand correctly that you mean "it's good to have helper > functions [1] that make code clean and tidy. It is also good to be > able to look at the code of such function and create your own > derivative function if necessary"? > > If so, that's like +111 from me - couldn't agree more. > > [1] or other helper stuff, even if technically it's not a function I would not call "an interface to a musical concept" a "helper function" just because it is reasonably easy to translate that concept into a graphical representation. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
