>> Uh... how helping fix compiler bugs? Could we help with that? I feel that's 
>> *much* more
important than benchmarking, for instance, since it doesn't make sense to 
benchmark something if
it has bugs. :\

> I have the same feeling. I'd like to see such projects. But I believe 
> students are more likely
to pick feature-oriented projects. The stuff that sounds cool. Compare: I 
implemented a Garbage
Collector for D that improved performance dramatically vs. I fixed bugs in the 
compiler. I do not
think that fixing bugs is less demanding. Actually I do believe it's more 
difficult and it is
fun. You know the feeling, when you finally understand what's the cause of the 
problem and when
you know how to fix it properly. Do you have an idea for packaging fixing bugs 
in a way that
makes it
look more interesting?


100% agree. :) I'm a student myself and I'm really considering GSoC for D, but 
from my own
perspective I'd only do it if I could fix bugs in the compiler -- *that* is 
what I truly enjoy
doing (since I really want to help D become more popular), and _not_ timing the 
application's
performance. Benchmarking would just be like mopping the floor for me... it's 
important in its
own right, but I'm not sure if college students would actually enjoy doing it; 
I certainly
wouldn't.

(Personally, I think *THE* most important factor that's hindering the adoption 
of D are the
compiler bugs, _not_ performance. If people can't write correct code, they 
wouldn't even give a
second thought to optimizations; I think putting workforce toward optimization 
is a bit premature
at this moment.)

Reply via email to