Hmmm. If $100M was on the line, the project code base must be extremely large. Correct?
With a code base of that size, more than half would be common or boilerplate functionality, e.g. read a config file, read a data file, write/update a file, parse the command line, maintain a list, put up a window, etc. All been done before, all mundane, all "boring". There would be 20-30% of truly new code specific to the project. Not really boring code, not really exciting code. Probably wouldn't require any specific language features. I would worry about large-scale project support from the language, e.g. package/module isolation, minimal compilation time, debug support, etc. IDE availability and tool support in general would be factors too. And finally there would be 5-10%, perhaps less, of the code base which was "exciting". It would require certain language features or capabilities that only a language like D could provide. Given that project layout, what I would want then is a language *and* development kit that had the full project requirements covered. If the "exciting" stuff could be covered by Java or C#, I'd use Java/C# since the vast majority of the "boring" functionality would be already available to me in the JDK/CLR. If the "exciting" stuff, could only be covered by D, then I'd worry how I was going to write all that "boring" code in time, especially if I had to guarantee some level of defect rate. The JDK/CLR rides on top of Java/C#, both OK languages with OK features. Having the JDK/CLR available and tested by millions of developers? Very, very appealing. I could of course redevelop or convert, for example, a DOM XML parser in D, but that takes time. Would I want to spend the development time and debug time in this project to hit a low defect rate on boring code? Or would I just go with a language & development kit that already had a wide code base and known defect rate. Generally speaking I believe low defect rates are due to time passing - get a large number of people kicking at a bunch of code over a long period of time, eventually the bugs get fixed. The concern is will there be enough time in the project for that effect to naturally run its course? So D right now has Phobos and Tango. Both are good, but not fully featured and, relatively speaking, untried. I could plan for a roll-yer-own development kit from scratch. Daunting. I could plan to patch together a whole set of converted C/C++ libraries. I could start with a conversion of Boost or something similar to D and add to it as I needed. But all this pales when compared to the 5,000/3,000 classes already written for me in JDK/CLR. That's a heck of a lot of code, all with a relatively low (and at least known) defect rate that I don't have to write. The less code I write, the more of that $100M stays in my pocket, right? In short, it's not D itself that would drive my decision to use or not use D. It is the extent and quality of the development kit that goes along with it. Of course, if the "exciting" part of the project was a solid fit with D then my decision would naturally swing that way. But if a language like Java/C# could do that part for me, I'd go with it and its JDK/CLR in a heartbeat. As a side note: the interesting twist here to me is that D language features themselves promote the possibility of a very high quality DeeDK. It would certainly be faster, and with enough unit testing and diligence, of a better quality than JDK/CLR could ever hope to be. John
