Re: critical issues

[David Kastrup]

"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.
c) Implementors are scarcer than users.

> In fact, I think that it is because of some sorta unified direction
> that for-profit programs can often miss out on adding experimental or
> innovative features.

Mike, just recently you said something like you had implemented
something along the line of spanbars, did not actually understand what
you were doing, it could not actually do the work you intended it to do,
but you thought there was nothing wrong with leaving it in until
somebody hit bugs caused by this code.  You can't debug or understand
this sort of experimental and innovative code, and if you can't
yourself, how can you expect anybody else to do?  This sort of bit rot
which nobody know how to either fix or remove(!) is _lethal_ to a
project.  A few dozen things like that, and nobody can make the product
stable again with reasonable amounts of efforts.  Instead you get
symptom-fixing, taking _huge_ amounts of resources in order to let code
nobody understand not hit fatal situations.  And the code not actually
doing anything useful or reliable is causing man-months of maintenance
work.

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.

Features and innovations come at a cost.  With good modularization and
infrastructure, their cost and benefits are mostly separable from
others: don't use them, and you don't get troubled by them.

LilyPond is not modular enough for that, and it does not have the
infrastructure.  Those don't fall from the sky, and if they are to fit
their purpose, they will require very little experimentation or
innovation but will be perfectly boring.

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.

-- 
David Kastrup