Right now, what's the most important for the success and adoption

[Ary Manzana]

I've recorded a video that shows what Descent will be able to do in the 
next releases. This shows more or less why me and Robert think a good 
IDE will improve development speed in D.

http://esperanto.org.ar/descent/descent.html

Of course, the functionality is the same as DMD, but being able to 
detect errors without having to compile helps a lot. Also, as you can 
see, you can evaluate compile-time functions on-the-fly by writing 
static asserts that fail.

Enojy!
Ary

P.D.: The video starts with "Let's start by defining a function..." (it 
got cut in the recording).

Robert Fraser escribió:
> BCS Wrote:
> 
>> -IDE
> 
> You're the first one in the topic to mention this. I agree with you quite a bit on this, as all the current IDEs, while sufficient for writing code, still have their faults. For example, no IDE at present can do code completion with this:
> 
> mixin(ctFunction());
> 
> char[] ctFunction()
> {
>     return "struct Foo { int bar,baz; }";
> }
> 
> Foo foo;
> foo. // Here's where I'd want code completion to come up and suggest "bar" and "baz"
> }
> 
> That's a trivial example, but all the compile-time stuff (templates, CTFE, mixins, etc.) is hard to debug properly because there's no real way to see the compile-time results. IDEs that have the compiler's complete semantic knowledge about these things can provide a whole host of features targeted at a mostly D-specific problem (I know C++ has templates, too, and I'm not sure what IDEs do to make working with them easier).
> 
> That's why I'm working on Descent (or, at least, will get back to it next week some time), with the hope that Descent can bridge the gap between very effective, feature-rich IDEs without full semantic knowledge (Mmrnhrnm or however you spell it is a really good example of it) and the compiler itself. Instant problem reporting and quick-fix functionality are also planned, so another piece to that bridge will be there as well.