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
---
----
Join the Frogs!