Frog's Lament

[Marc Hohl]

Hello all,

I followed the (partly very emotional) discussions about 
(un)documentated code
with great interest, and aside from the fact that I neither have the 
technical
arguments nor the knowledge, I mostly agree with David Kastrup.

As a frog, I feel supported very well from Carl et al., but nevertheless,
I see myself still throwing little stones at random in the pond, looking at
the ripples on the surface (to stay in the picture).

Well documented code is crucial in such a project for other developers 
to jump
on the train, so learning by RTF code isn't fun (as mentioned elsewhere) -
for me, it's annoying, it's frustrating, and it keeps me persistently 
feeling
too stupid even for the easiest tasks.

Ok, there are some who have absorbed the philosophy of lilypond, so they 
can deliver
great patches without asking one question on the list (kudos to them!), 
but I want
to improve lilypond, too, and I am not this sort of guy. And I think I 
am not the only one ...
The list support is great, but in the time necessary to answer all my 
questions on
a specific problem again and again, that person would have solved the 
task I am working
on more quickly and perhaps even more consistently that I do. Ok, this 
is not the spirit
of the whole frog thing, but I hesitate bothering developers with my 
questions.

So, while the code indentation policy is very strict, why don't we do 
something
similar concerning the documentation? If only patches are pushed that 
are well documented,
at least the improvements will be documented, and perhaps the developer 
has some time
to document bits and pieces of the code he is referring to, too.

It is clear that fully documentated lilypond code can't be written from 
scratch,
but we have to start somewhere, and if the patch doc policy is as 
restrictive as
the patch indentation policy, this will ease the work for future 
developers significantly.

Then, I miss some general information of the future goals. Ok, the bugs 
should be
eliminated, but rumor says that there are efforts to move functionality 
from c++ to scheme.
Is this true? If yes, would it be for instance possible to write a 
interface in c++
(kind of a meta-engraver) to allow engravers being coded in scheme? For 
people
deeply involved in the internals, this doesn't seem to be very 
important, but I think
it would improve the situation immediately.

I learned scheme for working as a frog, and now I am at a point where 
even the simplest
tasks (seem to) require some additional c++ coding, so I will have to 
learn c++, too.
On the other hand, my c++ code may soon be useless if someone writes 
such a meta engraver
interface; therefore I hesitate to put much energy into learning a new 
language.
Besides, not having to compile the sources ever and ever again makes 
development much
easier, quicker and more reliable.

There has been a lot of emotions and some kB of mails in the last days, 
so there is
a strong will to improve lilypond; without insulting anyone, I would ask 
the core
developers to try to see the whole story from somebody's point of view 
who has no
clue where to start, limited time, but nevertheless the will to make 
things better.
The community cannot afford to drive away possible developers by giving 
them the feeling
that there is some inner circle where information flows and where the 
beginning
coder has no entry (sort of: "You don't understand the code yourself? Go 
playing with
your toys then.") I don't think this is the case, although it sometimes 
seems to be.

Greetings from the pond

Marc