|Original post by Stachel|
About all you said can be summed up in that D isn't in widespread use. Then you said D compounds C++ mistakes (while presumably C# doesn't). It's reasonable to ask what you mean by that. I'm curious what you see when you look at D.
I know, and it is reasonable. I just don't feel like going there. It requires too much discussion of what's wrong with C++ first, and I'm not interested in comitting that much time to this thread.
|As for me, I wouldn't use C# for the simple reason that it attaches me at the hip to one platform. What if you write the next big game hit in C#, and want to move it to the new Nintendo/Sony Gee-Whiz game box which has no .net on it?|
|D isn't in widespread use - agreed. But D isn't single platform, it's on several, and being integrated with gcc (GDC) means it's reasonable to get it on any platform I'd need it to be on.|
I don't buy that. First of all, if you want D on any platform other than the set that are supported -- which at the moment includes the major desktop and server operating systems, and nothing else. You're not doing any better than C# yet, and you're actually doing substantially worse than Java.
So then you go to retarget GDC to your new platform, let's say the PS3. First of all, that's a tremendous waste of time. Apart from the time spent on implementing the compiler and any supporting runtimes, you have to deal with compiler bugs that arise. Ok, so the frontend shouldn't have any bugs, but you have to rewrite the machine code generation, and that's very likely to be wrong for a while. You'll also have to re-implement the entire backend of the optimization system, or D still won't be usable as a core language. Don't forget, that includes building support for platform intrinsics (Altivec, etc) and making sure the compiler knows how to optimize those too.
Let's suppose you finished all of that. Now you can finally start building your game. Of course you're running many months late at this point, but moving on. Since you're using D for everything, you can't actually license third party middleware now, unless you're willing to write significant glue code. (In the case of a C API, like RenderWare, this might be possible -- in the case of PhysX or Unreal, you're in for a world of hurt.) So now you have to build your own engine completely from scratch. At this point you're looking at a total development timeline which is north of 4-5 years. Whatever console you were planning to launch for is probably obsolete
at this point. In order to support the next gen, you have to go back and fix GDC to deal with the new architecture, which is now an 80 core monstrosity...you see where this is going.
Now don't get me wrong, the above story applies almost verbatim to C#, just with Mono instead of GDC. That's exactly why professional development is is not using C#; being locked out of consoles is not acceptable. However, D doesn't really have an advantage in this area, nor does Java or anything other than the native language which the manufacturer is supporting -- which is always C++.
|Wouldn't PInvoke allow them to still use most of the legacy code? Or is that how they are able to do most of the new projects in C#?|
A lot of that code is application level, not library level. PInvoke doesn't really help there. That's not the important part though. You simply don't reimplement code that has been working flawlessly for a decade unless there's a really big problem with the system. There are much better ways of spending developer time.