Re: [GLISS] differentiating pre/post/neutral commands

[Jan Nieuwenhuizen]

Graham Percival writes:

>> On the one hand I very much appreciate the ideas and proposals, because
>> they tell me that people really care about our user interface.  This is
>> what people see of LilyPond and so it is easy to identify LilyPond by
>> it.  On the other hand, everything that does not result in a nice patch
>> is useless.  Or worse than useless if it wastes the development time of
>> David (and the courtesy time of Han-Wen).
>
> I absolutely disagree that "everything that does not result in a
> nice patch is useless".  Think about the Waltrop trip -- I think
> that the most valuable parts were seeing each other, eating
> together, talking about cross-cultural issues, looking at scores,
> hearing about Janek and Rudolfo's typesetting work, our
> conversation in the garden, etc.

Yes, of course; I agree and that's not what I meant to say.  Connecting,
socializing, talking is always good, but in the end, the idea of
technical discussions in a LilyPond setting is to produce a [better]
patch.  A patch documenting why something is a bad idea can also help.

> Don't get me wrong; all the work that you and John did on GUB was
> very valuable.  But if I had to choose between that set of patches
> vs. the time we spent on non-programming activites, I would choose
> the non-programming activities in a heartbeat.  I think that
> fostering a feeling of community is the best way to keep lilypond
> around for the long term.

Yes.

> That said, I _do_ agree that fostering the community is not the
> *only* goal that should be considered.  Not wasting development
> time is another goal.  That's precisely why I thought that "fluffy
> discussion" should take place on another list.

You can do that, and it may be a good idea.  I just wanted to share with
you how much this resembles what I've seen before and that syntax
changes are often easy to work out if you know what is possible and what
you're talking about.  If you don't know exactly what is possible and
who is going to implement an idea...

> Think back to having breakfast around the kitchen table in
> Waltrop.  Suppose I said "hey, I wonder if we could create some
> way to help users avoid being confused by whether a \command would
> apply to the note before or the note after?".  I think in that
> environment, we could casually chat about possibilities without
> anybody freaking out that I was going to jump into git and push
> some hacks to the parser.

Yes, only, you have no idea how many of those chats I had and how
little came out of it.

See, what I realise now is that we did not have a very clear goal
of where to go with the language.  It should be easy to learn and
take little keystrokes to enter and possibly also strictly define
music.  We never chose what aspect was most important.  Seen in that
light, I think we could have done worse.

And now things have become even harder to change.  Changes annoy
users and should not be done gratuitously.  More important than
agreeing on a change, would be to first agree on a direction.
One step you can always take is to simplify and clean up things,
which is exactly what David is doing.

> *That* is the type of environment I want to create.  I want to
> retain some of the magic of Waltrop, some of that feeling of
> *community* rather than an antagonistic "you're wasting my time"
> or "your patch breaks XYZ" that we see so often on lilypond-devel.

Waltrop was amazing, and it is impossible to lose that.  It has
already created.  The fact that so many of us met in real life
was immensely valuable and I'm sure that every one of us will
retain some of that spirit.  It cannot be undone :-)

> I disagree.  I do not think that musicians have nothing valuable
> to say.  I *especially* do not agree that documentation writers or
> teachers (in person) have nothing valuable to say.

That's also not what I meant.  David wrote a nice paragraph about
user feedback.  Quite valuable, if it is specific and precise,
hardly of any use if it is vague or addresses how things should
be done.  In the end, a developer needs to change the parser.  So
a developer needs to convinced something is a good idea.  Developers
are easiest to convince by sending them a clean patch.  Next is
a well thought-through proposal of something that is actually posible.
Random feedback like: this is annoying may also be helpful to steer
development.

Jan

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl