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

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> Am Mittwoch, 25. November 2009 10:02:55 schrieb David Kastrup:
>> It would have helped if the code I threw out had contained any
>> comments as to what problem it tried to fix, and what symptoms were
>> involved.
>
> Yes, that's also my main problem: The code does not contain any
> comments, so it's really hard to understand how something
> works.

I can deal with "how something works" most of the time, where concise,
reasonably well-purposed code is involved.  I've done this even with
disassembled code from hand-written assembly language.  One of the
best-designed programs I explored was a Reversi program in Z80 machine
language.  Totally consistent index register use, coherent data
structures, Alpha-Beta pruning implemented straight from the book,
scoring lookup tables in a good layout.  Every piece of code had a clear
intent and function.

I can read a story and plot written in a programming language.

But I can't reinvest the time others placed into designing workarounds,
making design decisions and the like.  Computer programs are not the
place for "Deus ex machina" plot twists and mystery novels.  Programs
need to be written like good children books, not making life more
trivial than it is, not hiding it, but also not making it more
complicate.

And where this is not possible because of external influences (like bugs
in guile), code comments must be there.

And if that is not the case, something is rotten.  And yes, rotten
things make me ill-tempered, and ill-tempered people are a nuisance.
Other people silently go away.

But that does not help.  The likelihood to find nice, friendly persons
that know to ask the right questions in the right way about undocumented
incomprehensible code written for opaque purposes and have the expertise
and experience to both deal with code that is not as it should be as
well as with the developers responsible for it, or at least knowledgable
about it, is not high.

So it is a waste of scarce human resources to even shoo apparent
assholes like myself away.

> That's one of the reasons why I haven't gotten deeper into lilypond
> development, simply because it's way too much work to try to
> understand the internal details...

I can work myself into internal details.  But not into those details
that aren't actually to be found.

>> By the way: anybody have a suggestion about why, even after make clean
>> and the like, my regression tests always bomb out with
>> 
> [...]
>>  WARNING: Unable to load the map file
>> Undefined subroutine &main:: called at
>>  /usr/local/tmp/lilypond/Documentation/lilypond-texi2html.init line 750.
>>  make[2]: *** [out-test/collated-files.html] Error 25
>> rm /usr/local/tmp/lilypond/./out-test/xref-maps/collated-files.xref-map
>> make[2]: Leaving directory `/usr/local/tmp/lilypond/input/regression'
>> make[1]: *** [local-test] Error 2
>> make[1]: Leaving directory `/usr/local/tmp/lilypond/input/regression'
>> make: *** [test] Error 2
>
> Do you have texi2html CVS installed? The CVS version is under heavy
> development, so it currently only works with texi2html 1.82. (some
> internal functions were renamed, upon which our .init script relies.

Sounds like a dependency impacting developers rather severely.  I don't
have Python experience so can't get into it.

Maybe it would make sense to place a copy of texi2html into the Lilypond
source tree as long as Lilypond can't avoid meddling with internals of
texi2html?  Otherwise arbitrary breakage with versions out of the
control of Lilypond will remain to be expected.

-- 
David Kastrup