Re: LilyPond internships and LilyPond graduation projects. MusicXML export!

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> Now, there's an even more awesome thing: i've talked with another guy
> who coordinates the "team programming project" course for 3rd-year
> students (which results in undergraduate thesis for the team members).
> The thing is that the coordinator wants the projects to be as
> real-life as possible: some of the projects are actually ordered by
> companies.
>
> I've asked him whether it would be okay to have some LilyPond modules
> as the project, and he said that it's okay - Lily fulfills all
> requirements.  So, the students could for example implement MusicXML
> export, or implement advanced accidental spacing
> (http://code.google.com/p/lilypond/issues/detail?id=2141 and friends),
> or some other project (Mike's skylines is a good example of the
> project that could be done during this course).
>
> I think this is pretty awesome!  Maybe you could try this in your
> local Universities?  Having a horde of students working on LilyPond
> would be excellent, don't you think?

Well, there are a few drawbacks.  For one thing, LilyPond is an awfully
complex piece of work with a lot of snags, and those are for a large
part documented quite poorly.

Its core is written in C++, but it uses C macros in rather intransparent
manners to accomplish things.  The basic memory allocation is the
conservative garbage collection system of GUILE which is only loosely
compatible with C++.

The parser is written with Bison, but the lexical and syntactical
classes change dynamically and there is a lot of trickery involved since
the parse problem is not really LALR(1).

You can do a lot in Scheme, but then some stuff is not accessible.  It
uses the STL for C++ data structures, but avoids using iterators.  And
so forth and so on.  Basically all its infrastructure is not quite used
in the style it is intended to be used.

And we have lousy mentoring and lousy reviews.  So a lot depends on the
candidates' self-learning abilities, and our code base is such that it
is not exactly helpful with regard to self-learning.

Now that does not mean that there are not subprojects that could nicely
be handed off: I'm currently taking eternities for putting a geometric
algorithm to code, where all the thinking has been done and "only" the
"proper" coding of C++ classes is pending.  I'll probably cut this short
at some point of time and just crank out the _code_, never mind the
"proper classes".

But of course, coding a specific algorithm modularly would be student
level stuff.  Also, "GUILEv2" would be a term level project.  And so on.
There are several things at a level of complexity that is doable by
students.

But there is no reasonable insurance against failure.  If a student is
getting nowhere, there is little in the way of help we could reasonably
provide to get and/or keep him on track.

Of course, that's quite relevant "job experience".  In the "real world",
there are also ugly things.

-- 
David Kastrup