GSOC 2011

[Bruno Medeiros]

On 22/03/2011 17:47, Luca Boasso wrote:
> Hello,
>
> I am Luca and I am finishing my master in computer engineering. I am currently
> an intern at Panasonic in Cupertino.
> My great passion has been always programming language design and implementation
> and I am studying the D programming language.
>
> I like to play with different languages and in my master thesis I created a
> small DSL. I am familiar with parsing theory  and I wrote simple parsers
> by hand and with the help of ANTLR.
>
> I am really interested in the following ideas (sorted by interest):
> - http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#LexingandParsing
> - http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#ANTLRandJavabasedDparserforIDEusage
> - http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#DtoolsinD
>
> I think that I can give my contribution and I would be more than happy to work
> with you. This would be for me a great opportunity to contribute to an open
> source project and a way to learn more about D and parsing.
>
> Could you give me more information about the help needed?
>
> Thank you
>
> Luca Boasso

The student is free to present their own ideas, or to flesh out in more 
detail a proposal for existing ideas. The first two items 
(LexingandParsing, ANTLRandJavabasedDparserforIDEusage) are fairly 
concrete ideas.
The last one, D Tools in D is far more general, and can involve a lot of 
different things. But there are two things that I would like to say 
regarding that one. First, I think that for GSoC we should focus only on 
proposals that, if completed successfully, would be usable and useful on 
their own, or add something of value to another project/tool/library 
that would be useful. In other words, I don't find it desirable to work 
on a project that would need more work done on it afterwards to only 
then make a usable tool or library (for example a D-based D parser).
The second, partially related to the above, is that I find that writing 
certain kinds of D tools in D is a huge waste of time. The prime example 
is IDE stuff. It is crazy to be reinventing the wheel here, to not use 
the frameworks and functionality that existing IDE platforms (Eclipse, 
Netbeans, Visual Studio, etc.) offer. (More like rebuilding a castle 
than reinventing the wheel) In this IDE case, building a tool in D is 
only worthwhile if you are able to integrate it with the IDE platform. 
For some kinds of tools, like build tools, debuggers, this is fairly 
easy. But for parsing and semantic functionality (for example, code 
complete), it is much harder. But it is not unheard of. For example the 
Goclipse plugin (Eclipse-based Go IDE) uses Gocode - an external daemon 
process - for its core semantic functionality. (I haven't tried it yet 
to see how well it works). But it's all very like the ideas presented 
here: http://vimeo.com/16069687 by Steve Yegge regarding new toolchains.
My overall point is that people should think of delivering something of 
value to D developers, and not just an incomplete project. And also make 
it as sustainable as possible (easier to keep up to date with changes in 
D or other tools).

Of course, all of this is my personal opinion, and doesn't necessarily 
reflect the opinion of the rest of the community, or the D GSoC umbrella 
organization.

-- 
Bruno Medeiros - Software Engineer