Re: I'd like to help and solve <> misunderstanding - if i can...

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Tue, May 8, 2012 at 10:21 AM, David Kastrup <address@hidden> wrote:
>> Janek Warchoł <address@hidden> writes:
>
>>> On Mon, May 7, 2012 at 9:54 PM, James <address@hidden> wrote:
>>>> If this were some obscure change that 'most' LP users didn't use -
>>>> '#{ ... #}' seemed to get everyone really excited for instance, I
>>>> just shrugged, I've never used it, don't even know why I would or
>>>> if I could or when I shoul. Or maybe I have but didn't know it?
>>>
>>> If i understand correctly, everyone uses Scheme functions all the
>>> time: when you \transpose, you use a Scheme function.  \relative is
>>> also a Scheme function.  There is lots of Scheme wrapped nicely in
>>> commands starting with backslashes.
>>> When the #{ ... #} change was made, i didn't see any change in my Lily
>>> workflow, too.  I still don't know what exactly that change meant (i'd
>>> like to learn this some day, though).
>>
>> It means that the non-programmer types can escape from having to use
>> Scheme almost everywhere.  Instead of having to write
>> (ly:make-pitch 2 3 1/2) in Scheme code (and music functions are Scheme),
>> they can write #{ fis''' #}.
>
> Thank you for explaining this for me.  Until now i thought that it
> already worked like this...

Oh, it would have worked in 14.1 already, but the result would not have
been a pitch, but rather a SequentialMusic with an 'elements property
containing a list containing an EventChord event with an 'elements
property containing a list containing a NoteEvent event with a 'pitch
property containing the actual pitch.

My initial work on #{ ... #} got rid of the SequentialMusic, unrelated
work got rid of the EventChord, and the named commit got rid of the
NoteEvent.  Nobody cares since people are used to #{ ... #} being
useless for most purposes.

But new programmers will at some point experiment around with it and
won't be surprised by things working like one would think they should.
And they start helping others on the user lists, because it's not really
all that hard.

And some of them are paying money, partly quite non-trivial amounts,
because they trust I know what I am doing.  That is quite a substantial
amount of "thank you".

But the developer list and the vetting process is not exactly a
rosegarden.

> You can see that i'm quite ignorant in this area :( I didn't realize
> how many things need fixing; i took for granted that everything works
> mostly fine.  This may be the reason why i didn't appreciate your work
> enough: i didn't understand it.

Much of my work is focused on making things such that they make sense.
I don't think that what one can make LilyPond do has changed all that
much because of my work.  It's more that _how_ you can make it do things
is changing.

>> Check out the enthusiastic reviews for this one:
>> <URL:http://code.google.com/p/lilypond/issues/detail?id=2286>
>> <URL:http://codereview.appspot.com/5633043>
>
> I am sorry that i didn't manage to review your patch.
>
>> Of course, not everything is apathy.  If I get feedback, it is
>> commonly in the form of
>> <URL:http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00247.html>
>> or similar.
>
> I'm sorry :(

Too late to run, your GSoC project has already been accepted.

>> Finch's landing all over.  Which reminds me: "To Kill a Mockingbird"
>> is definitely very good reading, and not just because Groklaw and
>> lawsuits have recently becoming much more ubiquitous.
>
> Sorry, but i don't understand what you mean, perhaps because i didn't
> read that book.

Do it.  Trust me on that: you will be glad you did.

-- 
David Kastrup