Re: [frogs] Frog's Lament

[ Thread Index | Date Index | More lilynet.net/frogs Archives ]


Sorry, some Germanism found its way into the mail,

sed "s/documentated/documented/g"

;-)

Marc

Marc Hohl schrieb:
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!




---
----
Join the Frogs!


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/