Re: critical issues

[David Kastrup]

"address@hidden" <address@hidden> writes:

> On Jan 5, 2012, at 9:14 AM, David Kastrup wrote:
>
>> "address@hidden" <address@hidden> writes:
>> 
>>> On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote:
>>> 
>>>> Correct me if i'm wrong, but my impression is that
>>>> there is no particular direction in which we are going.
>>> 
>>> I'm sure that other people have their pet projects as well.  The
>>> ensemble of these projects is the "direction" of LilyPond, and I don't
>>> see why it would need more of a direction that that.
>> 
>> Because
>> a) LilyPond becomes unmaintainable if everybody implementing his own pet
>> project implements his own pet infrastructure and pet APIs for it.
>> b) LilyPond becomes unusable if everybody implementing his own pet
>> project does not bother paving the path for slightly similar pet
>> projects.
>
> I agree with this - I should have added that those who are
> contributing to LilyPond should do so in a way that favors
> extensibility.

If everybody does it in his own local way, it is more a distraction than
anything else.  "How does one do x in LilyPond?" "Depends on whether you
are talking about functionality written by Mike, David, Han-Wen, Jan,
Graham, Carl or Werner".  That's not what a user wants to hear.

> I agree with the "something like" part of your statement.

If I have something like a fire-breathing dragon with a hunger for human
flesh in my backyard, that is scary enough as a starting point for me.
Even if I got the details wrong.

>> As opposed to an artwork, _any_ corner of LilyPond, no matter how
>> small, can _ruin_ the rest.  You tend to think of bugs and bad code
>> of blemishes at most, when they are actually more like fungi that
>> will eat through the whole canvas and cause it to fall apart.
>
> This is not how I think of bugs.  If I thought of bugs like this, I
> wouldn't have taken the time to squash so many bugs in LilyPond over
> the past several months.

Well, "bug" was probably the wrong word to use here.  A bug is an
isolated phenomenon.  Squashing bugs is fine in itself, but if you find
yourself excelling at it, at one point of time you should probably
rather think about how to better lock your alimentaries away.

>> And if the LilyPond code does not make great strides in the direction
>> of becoming boring by doing everything the same way, projects like
>> "use linear programming" will be dead in the water since you can't
>> streamline a garbage heap of disparate code into doing linear
>> programming if you can't even make it do the same things in the same
>> way everywhere before changing that way to a linear programming one.
>
> I agree.  For example:
>
> The new StemTremolo code does less internal moving of the stencil and
> farms this out to callbacks.
> The new Stem code is decoupled from the Flag code and now behaves
> (along with the flag) more like other grobs.
> The Beam scoring code now looks more like the Stem and Tie scoring
> code on the inside.
>
> I did not work on these projects expressly in order to make LilyPond
> more uniform, but in working on them, I tried to move LilyPond to a
> state where its code was uniform.

Well, uniform code is nice, modular code is better.  You don't need to
worry about uniformity if everything actually calls the same code.  And
if you need to change how it works, being able to do it in one place is
much less likely to cause problems.  Of course, that needs to touch
foreign code in a lot of places instead of just leading by example.  And
that's where actual leadership is helpful since it can _make_ people
change their _own_ code, and they usually are much better qualified to
see problems in connection with those changes than a self-appointed
global janitor can hope to be.

> I think a good policy is that, when working on that which one wants to
> work on, one should always strive to do it in a way that leads to
> better maintainability and extensibility.

If those efforts are not coordinated, there is no end user benefit.
He'll still have to learn the individual ways of every part of LilyPond
he is going to work with.  And if the individual ways are all different
but still over-generalized, this becomes more of a distraction than a
benefit.  Generalization is not useful as an example or a proposal in
some corner of the code.  It makes only sense if it is pervasive.  And
if it is left to the individual's discretion, it can only become
pervasive when the individual is working _everywhere_.  LilyPond has
grown beyond the scope of a single-person project, however.

> <taken only slightly out of context>
> There are again two methods of removing the causes of faction: the
> one, by destroying the liberty which is essential to its existence;
> the other, by giving to every citizen the same opinions, the same
> passions, and the same interests.

[...]

Diversity is nice in a community.  It isn't in a program.  And it isn't
all too much in a single entity like a person, either.  There is not
much you can sensibly talk about with a fanatic conservative liberal
antisemitic orthodox catholic Chassidim.


-- 
David Kastrup