Re: stepping down as project manager

[David Kastrup]

Graham Percival <address@hidden> writes:

> - triplets written with 3:2.  I'll probably use python for the
>   language, so having a dictionary of hard-coded rules like
>     "\tuplet x:y" => "\tuplet y/x" (or \times y/x )
>   will be really easy.  And since it's a python script, it would
>   be easy for any user to modify that list of hard-coded rules
>   to suit their needs.

The problem with that kind of preprocessing is that it is not robust
against things like interspersed comments, or spaces in unexpected
places and so on.  That's one of the things that working on convert-ly
frequently shows.  It is also one of the reasons that C++ "deprecates"
the C preprocessor and tries providing mechanisms for most problem
classes "within" the language.

> - triples can also be written with integers, i.e.
>     a4 c a6 c e
>   Due to the easy-to-parse language, it won't be hard to replace
>   that with
>     a4 c \times 2/3 { a4 c e }
>   in the final .ly file.

If the editable form of your music is not .ly, then it might make more
sense aiming for MusicXML as your conversion target.  Python will sport
libraries supporting XML generation, and MusicXML is presumably more
dependable than LilyPond syntax.  Of course, LilyPond has no MusicXML
reading mode right now, so this again suffers from being based on
forward-looking expectations currently.

>> Trying to pin down decisions before the required knowledge
>> and experience are available does not make things easier.
>
> Funny that you mention that.  I was talking about the situation
> with my oldest friend (now a professional programmer for the past
> 11 years).  He couldn't believe that I was spending so much energy
> arguing with people who argued against project requirements on the
> basis of the current implementation.

There is a fine line between arguing on the basis of the current
implementation, or arguing on the basis of the current _design_.
Replacing arbitrary choices by other arbitrary choices is not progress.

> I tried to defend it as being a matter of volunteer open source
> vs. professional programming, but it felt a bit weak.

That's because it is weak.  I am one of your main sources of
frustration, and it is not because of unprofessional programming.  And I
am putting my potential to more effective use than you could plan.
Which is not really surprising since I actually also put my potential to
more effective use than _I_ could plan, as I am really bad at making
plans and following them.  Managing a project consisting of a rather
heterogenous worker setup with wildly differing degrees of skills and
directability is certainly a really tough task, and you fare
surprisingly well with that.  In contrast to my perfectionism regarding
code, for your perfectionism regarding workflow there is no "rip out and
rewrite" ultimate cure.  You can work on the tools, but you have to live
with whatever workers you are given.  Yes, a "professional" manager has
the option of firing and hiring until he has a crew fitting _his_ style.

But believe me: what you have to work with (and I am just a small part
of that) is actually quite a dedicated and capable work force.

> A few people here have pointed out that designing a new language from
> scratch is very different from modifying an existing language.  Well,
> that's what I've decided to do.  Start a new language, with no
> guarantees of supporting the wide range of sheet music that lilypond
> supports.

That range has actually rather spotty coverage.  We need to make
covering the rest easier and more systematic.  I am working on that, but
that's something you'd rather do in a different way and language.  What
you will depend on will be more the backend of LilyPond, and for
applications like yours, we'll likely be best off providing a MusicXML
path into that backend.

All the best

-- 
David Kastrup