Re: [GLISS] basics

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Wed, Sep 26, 2012 at 9:52 AM, David Kastrup <address@hidden> wrote:
>> Janek Warchoł <address@hidden> 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