Dejavu

[Robert Clipsham]

I don't know if anyone else shares similar feelings to me, but I've 
recently been getting feelings of dejavu with respect to peoples 
perceptions of the future of D. I wondered if it was just me, it seems 
that I had been reading similar things again and again though.

http://www.digitalmars.com/d/archives/digitalmars/D/The_proper_case_for_D._92245.html
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=92367
http://www.jfbillingsley.com/blog/?p=53
http://h3.team0xf.com/devlog/?p=16

These are just some of the posts I've read, which all seem to have given 
(or triggered) similar feelings about the state of D, although I'm sure 
if I tried I could find a bunch of others.

These opinions keep coming up, but from what I've read, very little 
action is being taken. As mentioned in Tomasz's blog post, some progress 
seem to be being made with respect to D, the likes of QtD and Descent 
appearing, I'm not convinced enough is happening though. If what I've 
read is correct, D2 will be marked as stable later this year alongside 
the release of TDPL, and there are still a number of issues which I 
believe will prevent D from rising to its rightful place alongside C and 
C++.

== The Spec ==

Most notably is the incomplete/vague specification which is something 
we, the community, are able to fix. If we work together to identify and 
repair the parts of the specification which are lacking (quite a lot of 
which is already identified in bugzilla), we could build up a new, more 
complete, version of the specification which could then be submitted to 
Walter for review. This needs to be done before D2 is marked as stable, 
as I doubt any larger modifications would be accepted after TDPL is 
published and D2 is stable.

== The toolchain ==

The next issue that seems to come up time and time again is the current 
state of the D toolchain. I believe the biggest issue most people have 
with this is OPTLINK, something I personally have never had any trouble 
with! (Yes, I am a linux user :P). Fixing this is somewhat more 
difficult, as it requires either: Putting pressure on Walter to fix it 
(I personally believe his time is better spent working on the compiler); 
Finding/writing a linker that supports OMF that could replace OPTLINK; 
or adding support for COFF to dmd. If this is to be achieved by us, huge 
amounts of effort will be required, although my knowledge on this topic 
is limited, having never encountered it first hand.

=== Phobos/Tango ===

I'll keep this short, as if D2 *is* just around the corner then this 
isn't too much of an issue (for now). What is important is that Phobos 2 
is complete. I believe another possibility if completion is not possible 
before D2 is marked stable is to separate D and phobos. At the point of 
D2's release there should be a complete feature set listed, if not 
implemented/complete. This will allow Phobos 2 to be completed on a 
larger time scale, and if we provide input on what we would like to be 
in the final phobos 2, then we won't/shouldn't have issues later on with 
another standard library/runtime being created as was the case in D1.

=== Debuggers ===

While I have had no problems debugging D apps, I believe there is still 
a lot more that could be done. Getting the patches to gdb into the main 
gdb distribution would be a huge step, at least for linux/osx/bsd etc. I 
am also lead to believe that dmd does not output the correct debug 
information on linux (from Jarrett's post, I haven't experienced this 
first hand), if this is correct a patch needs to be made and submitted 
in bugzilla.

=== IDEs ===

I don't really need to say much here, Descent seems to be getting along 
nicely. Needless to say I'm sure Ary would love any help we can give to 
improve it!

=== Build tools ===

OK, I'll admit, I just copied/pasted Jarrett's information here:

Build tools.  D’s module system makes it a natural candidate for 
automatic dependency detection, and some make-replacements have sprung 
up to that effect.  Bu[il]d, DSSS/Rebuild, and now xfBuild are the main 
contenders.  Some other minor ones include jake and di0xide (D0xD? 
deeoxid?  I can’t remember what clever spelling it uses).  Bud hasn’t 
been updated in a long time, which is annoying, since there are some 
really irritating bugs.  DSSS/Rebuild haven’t been worked on in several 
months since the maintainer went to grad school and stopped having time. 
  xfBuild is very new.  Installing and using any of them can be kind of 
an adventure, just like anything else in the D toolchain.

=== Installing ===

Leading on from Jarrett's comments, installing a full toolchain is... 
well... not easy. Again, this is improving, with the likes of the 
nightly ubuntu packages of ldc and qtd, it would be good if we could 
come up with a way of allowing a full toolchain to be as easily 
installable on all systems.


I'd like to know what you think on each of these matters, and hopefully 
inspire us to take some action to make sure D succeeds. I'm sorry if 
I've got any of my information incorrect or if I've just rambled on 
anywhere. I think D is a great language, and I'd hate for it to fail. 
After reading multiple posts where issues have been brought up but not 
taken anywhere, I thought I'd take a shot at it.

Robert