[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 26 Nov 2009 10:56:05 +0100
Thunderbird 126.96.36.199 (X11/20090817)
I followed the (partly very emotional) discussions about
with great interest, and aside from the fact that I neither have the
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
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
too stupid even for the easiest tasks.
Ok, there are some who have absorbed the philosophy of lilypond, so they
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
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
So, while the code indentation policy is very strict, why don't we do
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
but we have to start somewhere, and if the patch doc policy is as
the patch indentation policy, this will ease the work for future
Then, I miss some general information of the future goals. Ok, the bugs
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
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
Besides, not having to compile the sources ever and ever again makes
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
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
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
coder has no entry (sort of: "You don't understand the code yourself? Go
your toys then.") I don't think this is the case, although it sometimes
seems to be.
Greetings from the pond
- Frog's Lament,
Marc Hohl <=