A few thoughts on the existing GSoC student proposals

[Andrei Alexandrescu]

Hello everyone,


I've been following with interest the three preliminary proposals made 
so far: ANTLR grammar by Luca Boasso, containers by Ishan Thilina, 
Thrift bindings by David Nadlinger aka klickverbot, and database API by 
Christian Manning.

There are many issues to consider when looking over such a project 
proposal, and there's no quick and easy formula. The considerations include:

- Project impact: what would be the impact of the project? What 
consequences for D's adoption can be expected following the project?

- Project's chances of succeeding: what is the assessment that the 
project can be completed within the timeframe?

- Student match: what is the match between the student's initial skill 
set and the project?

- Mentor match: is there a strong mentor for the project?

Here are a few considerations regarding the three pre-submission 
proposals discussed herein:

1. ANTLR grammar for D

I think this is a feasible project. My main concern remains the 
projected impact. If the project is meant to build an ANTLR parser on 
the off chance that someone will later use it for Eclipse integration or 
otherwise, then there are serious concerns about the impact.

If, on the other hand, the project is focused on Eclipse integration 
(perhaps starting from an existing similar project) and uses an 
ANTLR-based parser as a mechanism to achieve that goal, then the impact 
would be significant. However, there is the concern that the scope of 
the project might be too large to be finished in time. So I recommend 
attention in defining the definition and scope of the project when 
writing the proposal.

The fact that we already have a good, supporting mentor in Bruno for an 
Eclipse project should help a lot.

2. Containers

I'd need to hear a lot more about this proposal before making an 
impression of it. From the little I gathered so far, I think this would 
be a difficult project to carry through. At this point D's containers 
need less solid coding but more design. Such design artifacts are most 
likely to come from an experienced member of the community. Starting 
from scratch in understanding the issues involved up to the level of 
making a solid contribution is possible, but difficult.

3. Thrift bindings

This is by far the best proposal we have so far. It comes from an 
established member of the community who has a good understanding of D, 
and is likely to boost adoption of D at companies that use 
service-oriented architectures, and Facebook in particular. If the 
project will be of adequate quality, I should be able to contribute it 
to the Thrift mainline. The impact could be decisive.

4. Database API

This is a high impact item. I'd need to collect more information about 
the specifics of the application before creating an opinion about its 
chances of success. I see Piotr and others have some related ideas; I 
suggest them to apply appropriately (either as mentors or students). A 
solid mentor(s)/student(s) combo is a key ingredient of a successful 
project.


Thanks,

Andrei