 | Posted by Robert Clipsham |  Permalink Reply |
|
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
|
