Re: What's the deal with the module system?

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Wed, Nov 25, 2009 at 8:19 AM, David Kastrup <address@hidden> wrote:
>
>> I have my doubts that Lilypond can develop into a sustainable project
>> from the current state of core mind and code.  Projects like the frogs
>> are nice for recruiting people, but if they are locked out of engagedly
>> working with parts of the core for technical and social reasons, this is
>> ultimately going nowhere new.
>>
>> New people can't pick up the slack if they are not shown the ropes.
>> Those that do the heavy lifting, not the whips.
>
> You currently have 5 commits in the master tree, a few one-liners and
> the largest touching about 50 lines.

And several dozen mostly exasperated mails on the developer list, posted
patches, including on Rietveld as demanded.  All those reflect much more
time investment than what is actually accepted or even commented on.

> Why don't you try getting smaller patches -whose effects you can
> oversee- in first before trying to radically change core system?

Because the stuff which I need Lilypond for requires me to work with
more parts than those which I presumably are supposed to touch.  Since
the parts are largely undocumented and questions about them are mostly
ignored or met with derision or even misleading information from those
who have already worked with the code, I am dependent on understanding
the code.  Where the code does things with a complexity without
explaining the reasons, and with its developers refusing to comment on
the reasons, there is not much that I can do except trying to simplify
it to the degree where I can hope to work with it.

> There is a lot of subtlety and a lot of history behind the way things
> are now,

Subtlety is a bad thing in software.  A really bad thing.  And history
is usually also a history of dead ends and failed attempts.  Both _need_
to get documented in order to keep history from running in circles.
Culture is the passing on of knowledge, keeping others from having to
reinvent wheels.  Progress means standing on the shoulders of giants.
That is not possible if they run away.

If I have to invest the same time into Lilypond as you did to arrive at
the same point, there is no point in working with you.

> and I don't have the time to explain them to the level of detail you
> seem to need for being productive.

Most of the questions I asked would be answered in 10 lines or less.  I
have invested by now several workdays in getting answers to the
questions

a) Where are artificial, where technical, and where logical
implementation borders between grob properties and context properties
and their accessors?

b) What is the toplevel module manipulation in markup-init.ly trying to
achieve and why?

Both can be likely answered in 10 lines or less by those who actually
wrote the code or participated in its previous discussion.

With b) I am currently at the point where it appears that the
markup-init.ly stuff tries exporting definitions one level upwards of,
well, the top-level.  The code does not contain any comments, there is
no explanation of why a propagation beyond the top-level is necessary,
the checkin does not contain any history (it is just a one-time
checkin), the crashes this is supposed to avoid judging from the
developer list discussion at the time of the checkin in 12/2006 are not
repeatable on my system, after everybody yelled at me that contributions
would not be manageable without putting them up, I placed the work on
the syntax at <URL:http://codereview.appspot.com/160048/show> where a
single person (AFAIU not one that would be comfortable judging its
technical merits) reviewed it and commented on a trivial documentation
problem.  Appreciated, but not in the same league as the many
admonishments I got for following the "proper" procedures.  In
particular since this was not done by one of those clamoring for me to
follow the rules.

At some point of time, when you are trying to make a new horse do
tricks, you need to have _some_ kind of reward rather than letting
matters just drop again.

Undocumented code is not maintainable.  Throwing it out is a matter of
sanity if it can't get documented, and it apparently can't.  It
apparently can't even get questioned or discussed.

How do you suppose that getting new core developers is going to work?

-- 
David Kastrup