Features that worth to look at

DDT is still quite immature so there are plenty of features missing to make it a productive development environment. Browsing in the code and messing with the product it self I decided to come up with an approximate list of features which should be implemented in order to make DDT worth to work with as a IDE for D development in the long run. The following list will change a lot in the future as I will revisit in the light of ongoing development.

Static and Dynamic library support: In a real software ecosystem static libraries are essential more than anything else. To add the static library support seems easy, but I haven’t tried any dynamic library with D yet.

Debugger support: This is perhaps the biggest one. There is no development IDE without a useful debugger interface and unfortunately DDT is lacking one. And also, this is quite a problem with D in it self. As far as my experiments went, the only compiler that produces some meaningful debug-info is DMD, but we have a limited support for command-line based debuggers. GDB would be a perfect choice, but at the moment I have no convincing evidence that the GDB’s D support is working to this moment. I need to investigate the matter further.

Refactoring: The CodeAssist for D is quite promising and I don’t see any issue to implement the most popular refactoring strategies: it’s just matter of time and arse.

Unit-testing IDE integration: It is imperative in the software development these days to offer a good, reliable testing facility for the developers. JUnit has an excellent support in Eclipse, where you can track in a graphical way what unit tests are present in the source code and we can have a good report on their progress in the test view.

As a frame work, I think it worth to have a look at the Felt project as it is aimed to provide all the agile goodies through several library. The DUnit framework in particular provides the unit testing framework which I could build a IDE support for. The real deal here is to parse the output of the unit test executable. Unfortunately it seems to rely on the Tango library which I find quite disturbing as the Tango is an optional library, but in this case all software that would use the Felt libraries, will depend on Tango. As the Felt library was updated quite a long time ago, as I try to explore it, I should remove the dependencies to the Tango library.