"m...@apollinemike.com" <m...@apollinemike.com> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel