[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

From: David Kastrup
Subject: Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
Date: Sat, 05 Nov 2011 23:31:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

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

> On Nov 5, 2011, at 12:27 PM, Keith OHara wrote:
>> I worry because you make the spacing given to bar lines rather
>> independent of the printed extent of bar lines, and the way you
>> calculate the space uses a part of LilyPond that I find hard to
>> understand.
> It took me months to get my head around it.

We don't want subsystems like that.  The bulk of any code should look
like anybody with half a brain could work on that.

Complexity needs to get compressed into strategic places,
infrastructure.  You don't want it spread all across the town.  If there
are three pages of code that take you a week to understand, that's ok if
they make hundreds of pages simple.

A good strategy is to always think "how would I like to describe the
problem to a program".  And then you do it.  And _then_ you start
thinking about what it takes to actually perform the task put into the
description.  _Without_ rewriting the description.

You may call that "object-oriented" thinking.  Sometimes you can't
escape your tools: I am currently working on the parser, on argument
scanning.  And the arguments are placed in the grammar in opposite
order, and recursively reduced by rules with limited lookahead.

That's a total nuisance and headache.  If you have a rule "after the
first optional argument in a row gets skipped, all following optional
arguments until the next non-optional get skipped as well", you need to
translate it into "you end with a non-optional argument, those can be
preceded either by non-optional arguments or by optional arguments, but
once one optional argument in a row gets kept, all preceding optional
arguments need to be kept as well".  Thinking backward in time is icky.

And one often has a reversal in time, or in flow control, that is just
making things awkward.

It is an art to design mechanisms that make a task describable in the
most straightforward manner.

> This is not unwise.  I toyed around once with the idea of writing some
> documentation for the CG that discussed how pure things work in
> LilyPond but spent time on other things - would that help?

I find that writing documentation helps me: because when things are far
too ugly to write about, I tend to change them, and _then_ write about

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]