digitalmars.D - Would You Bet $100,000,000 on D?

writes Peter Alexander I recently stumbled across this (old) blog post: http://prog21.dadgum.com/13.html In summary, the author asks if you were offered $100,000,000 for some big software project, would you use your pet programming language? This is interesting, because if we answer "no" then it forces us to think about the reasons why we would *not* use D, and perhaps those concerns are what we should be focusing on? --- To get the ball rolling, here are the reasons I would not use D for a big project with high stakes: 1. If I had to port to ARM, or PowerPC, or some other architecture then I would very likely have trouble finding a compiler and other tools up to the task. I wouldn't have that problem with (say) Java or C. 2. I'm not convinced that any of the available compilers would cope with a very large code base. I don't know what the largest D2 project is, but I think I would be right in saying that it has less than 1 MLOC. 3. Depending on what the project was, I would probably be worried about available libraries. If, for example, the project required the use of DirectX, I'd just use C++. 4. I'd be worried about garbage collector performance, although this is less of a concern than the others because it's not too difficult to work around if you know you need performance up ahead. 5. If I did use D, I would (and do) force myself to use only simple features. I would be too scared of the type system blowing up, or obscure template errors causing pain. One error I always seem to get when using Phobos is that it can't find a match for a function because the types somehow didn't pass the template constraints for some obscure reason. When there are multiple constraints, you don't know which is failing. Often it is due to the complicated const/immutable/shared parts of the type system. --- Essentially, I agree with his conclusion in the post. Tools and libraries would be my biggest concerns (in that order). The fact that D (usually) makes things easier for me barely registered when thinking about this.

writes Walter Bright On 9/16/2011 2:47 PM, Peter Alexander wrote: Essentially, I agree with his conclusion in the post. Tools and libraries would be my biggest concerns (in that order). The fact that D (usually) makes things easier for me barely registered when thinking about this. If you had $100,000,000 none of these are an issue, as you can easily afford to hire top developers to address any and all of them. There's a reason why huge companies like Microsoft, Google, Intel and Apple bring compiler dev in house. It's because they are so heavily reliant on compiler technology, they cannot afford not to.

writes Peter Alexander On 16/09/11 10:51 PM, Walter Bright wrote: On 9/16/2011 2:47 PM, Peter Alexander wrote: Essentially, I agree with his conclusion in the post. Tools and libraries would be my biggest concerns (in that order). The fact that D (usually) makes things easier for me barely registered when thinking about this. If you had $100,000,000 none of these are an issue, as you can easily afford to hire top developers to address any and all of them. There's a reason why huge companies like Microsoft, Google, Intel and Apple bring compiler dev in house. It's because they are so heavily reliant on compiler technology, they cannot afford not to. It's not just a question of "Can D do this?" but also "Is D the best choice for this?" For example, if the job was to produce a AAA video game that ran on PC, PS3 and XBox 360, I'm sure you could *do it* with D if you paid people to develop the compiler tech and tools to produce PowerPC code and interface with all MS's and Sony's libraries and tools. But would you?

"Nick Sabalausky" writes "Peter Alexander" <peter.alexander.au gmail.com> wrote in message news:j50h1v$ol8$1 digitalmars.com... On 16/09/11 10:51 PM, Walter Bright wrote: On 9/16/2011 2:47 PM, Peter Alexander wrote: Essentially, I agree with his conclusion in the post. Tools and libraries would be my biggest concerns (in that order). The fact that D (usually) makes things easier for me barely registered when thinking about this. If you had $100,000,000 none of these are an issue, as you can easily afford to hire top developers to address any and all of them. There's a reason why huge companies like Microsoft, Google, Intel and Apple bring compiler dev in house. It's because they are so heavily reliant on compiler technology, they cannot afford not to. It's not just a question of "Can D do this?" but also "Is D the best choice for this?" For example, if the job was to produce a AAA video game that ran on PC, PS3 and XBox 360, I'm sure you could *do it* with D if you paid people to develop the compiler tech and tools to produce PowerPC code and interface with all MS's and Sony's libraries and tools. But would you? I would. It would beat the hell out of trying to do everything in C++. Many different reasons: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). I'm sure there are smaller reasons too, but I'm convinced the primary reason why AAA game dev is C++ instead of D is ultimately because of inertia, not the languages themselves, or even the tools (If the AAA game dev industry genuinely wanted to be using D, you can bet that any tools they needed would get made). I'm sure there are a lot of pet languages out that wouldn't measure up to this test, even for the people who are fans of such langauges, but I've been with D *specifically* because I see it as a genuinely compelling contender. Languages that have limited suitability automatically turn me off. For instance, I'm a huge fan of what I've seen about Nemerle: But because it's .NET-only and doesn't have much (if anything) in the way of low-level abilities, I've never even gotten around to downloading the compiler itself, let alone starting any projects in it. I really don't even see D as a pet language. To me it's a bread-and-butter langauge. And I took to it because the other bread-and-butter languages were getting to be anything but: C++'s bread was getting moldy and it's butter rancid, and Java is more of a Wonderbread with "buttery-spread". Sure, sometimes the slices aren't even, and it might have some air bubbles, but that's still one hell of an improvement over rotten and/or manufactured.

writes Jonathan M Davis On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, and I suspect that given the current issues with the GC, if you were working on a AAA game, then you'd probably want the folks doing it to be good C/C++ programmers so that they would know how to do what needed doing when they can't use the GC or most of the standard libraries. For projects where performance isn't quite as critical, then D stands a much better chance of working. It _is_ easier to learn and has some definite advantages over C++. And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). I'm sure there are smaller reasons too, but I'm convinced the primary reason why AAA game dev is C++ instead of D is ultimately because of inertia, not the languages themselves, or even the tools (If the AAA game dev industry genuinely wanted to be using D, you can bet that any tools they needed would get made). As long as you stand much chance of running into a compiler bug, dmd just won't be up to snuff for many people. Most programmers are used to not having to worry at all about bugs in the compiler that they use. And tools are _very_ important to people, so D's lack of tools on par with many other, more popular languages is a major impediment. Yes, there's a lot of inertia that needs to be overcome for D to make a lot of traction in domains where C++ is currently king, but it's a lot more than just getting people to take a look at D. There are fundamental issues with D's current implementation which are a definite impediment. The situation is improving without a doubt, but it's still too rough for many programmers. I'm sure there are a lot of pet languages out that wouldn't measure up to this test, even for the people who are fans of such langauges, but I've been with D *specifically* because I see it as a genuinely compelling contender. Languages that have limited suitability automatically turn me off. For instance, I'm a huge fan of what I've seen about Nemerle: But because it's .NET-only and doesn't have much (if anything) in the way of low-level abilities, I've never even gotten around to downloading the compiler itself, let alone starting any projects in it. I really don't even see D as a pet language. To me it's a bread-and-butter langauge. And I took to it because the other bread-and-butter languages were getting to be anything but: C++'s bread was getting moldy and it's butter rancid, and Java is more of a Wonderbread with "buttery-spread". Sure, sometimes the slices aren't even, and it might have some air bubbles, but that's still one hell of an improvement over rotten and/or manufactured. I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. - Jonathan M Davis

"Nick Sabalausky" writes "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, Oh, definitely. But what I meant was that good D programmers can be cultivated. People can learn to be good at D. And while the same might *technically* be true of C++, the curve is so steep that it may as well be "what's out there is what's out there". It's, more or less, a non-renewable resource. And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). I'm sure there are smaller reasons too, but I'm convinced the primary reason why AAA game dev is C++ instead of D is ultimately because of inertia, not the languages themselves, or even the tools (If the AAA game dev industry genuinely wanted to be using D, you can bet that any tools they needed would get made). As long as you stand much chance of running into a compiler bug, dmd just won't be up to snuff for many people. Most programmers are used to not having to worry at all about bugs in the compiler that they use. And tools are _very_ important to people, so D's lack of tools on par with many other, more popular languages is a major impediment. Yes, there's a lot of inertia that needs to be overcome for D to make a lot of traction in domains where C++ is currently king, but it's a lot more than just getting people to take a look at D. There are fundamental issues with D's current implementation which are a definite impediment. The situation is improving without a doubt, but it's still too rough for many programmers. I realize I've said this other times in the past, but I find that the compiler bugs in DMD are much less severe than the language deficiencies of a fully-bug-free C++ implementation. Plus there's the idea of investing in the future to keep in mind: It's like the old quote: "I may be fat, but you're stupid. I can excersise and diet, but stupid will always be stupid." D may have some bugs, but investing the effort to deal with them will lead to further improvements. Dealing with C++'s problems, OTOH, will hardly do a damn thing. Sure, a few things can be mitigated somewhat, such as the C++0x^H^H1x^H^H2x^H^H3x improvents. But in general, investing the effort to deal with C++'s shortcomings won't lead to significant improvements - it *can't* because it's constrained by its existing legacy design (not that that won't eventually happen to D, too, but D is one generation past C++). Ie., D may be buggy, but C++ is crappy. Bugs can be fixed, but crappy will always be crappy. I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. FWIW, I had been a huge fan of C++ for many years and used it extensively ('course, that was quite awhile ago now...). And I *do* think it was a great language back in it's time. I just think that time is long since past. When I say "C++ is crappy", I mean "within today's context, and moving forward from here". It's like the Apple II: I respect it, and I have fond (and a few not-so-fond) memories of it, but neither of them would be among my first choices for serious work anymore. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. I'm certainly aware of all that, and I do understand. But the question here wasn't "Do you think OTHER people feel language X is suitable for serious work?" It was "Do YOU think language X is suitable for serious work?" I don't doubt other people would disagree with me (especially people who haven't used D, and even probably some who have), but my own answer is "Yes, I think D is suitable for such projects, and in such a situation, yes, I would be willing to put my money where my mouth is."

writes "Xavier" "Nick Sabalausky" <a a.a> wrote in message news:j51h52$2h0e$1 digitalmars.com... "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, Oh, definitely. But what I meant was that good D programmers can be cultivated. People can learn to be good at D. And while the same might *technically* be true of C++, the curve is so steep that it may as well be "what's out there is what's out there". It's, more or less, a non-renewable resource. It's not nearly as "steep" as it used to be, for C++, the tools, the techniques, the documentation, the users have matured and one need not struggle through everything on one's own anymore while learning it, but rather just go look up or ask for the answer, and it is still improving. Sure, if one exploits every "stupid template trick" and similarly with the other language features, then you will have "steep", but it is quite tractable these days if one isn't overzealous and able to separate all the jabber about "metaprogramming" and the like from the meat of the language. It will always have its warts, but D has many of the same ones. I realize I've said this other times in the past, but I find that the compiler bugs in DMD are much less severe than the language deficiencies of a fully-bug-free C++ implementation. That's an interesting, if not odd, statement considering that C++ are more alike than they are different. Plus there's the idea of investing in the future to keep in mind: It's like the old quote: "I may be fat, but you're stupid. I can excersise and diet, but stupid will always be stupid." The truth of the matter is, though, that she won't exercise to any significant degree and has been on a diet her whole life and her weight has continually increased. On top of that, the fact that one can study, research and learn escapes the fat dumb blonde bimbo because she indeed is stupid, and that's why her "dieting" causes her to gain weight instead of lose it. D may have some bugs, but investing the effort to deal with them will lead to further improvements. Dealing with C++'s problems, OTOH, will hardly do a damn thing. Again, I find that a curious statement for reason noted. The language names even fit together: C/C++/D. There is no denying that they are all related. Just look at those noses! C'mon! Sure, a few things can be mitigated somewhat, such as the C++0x^H^H1x^H^H2x^H^H3x improvents. But in general, investing the effort to deal with C++'s shortcomings won't lead to significant improvements - it *can't* because it's constrained by its existing legacy design (not that that won't eventually happen to D, too, but D is one generation past C++). One generation away, but still the same family. So what? Ie., D may be buggy, but C++ is crappy. Bugs can be fixed, but crappy will always be crappy. All adolescents conflict with their parents and say things like that. When D grows up, the D++ or E kids will be maligning D and then D will remember back how it was just the same when it was just a youngster. I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. FWIW, I had been a huge fan of C++ for many years and used it extensively ('course, that was quite awhile ago now...). And I *do* think it was a great language back in it's time. I just think that time is long since past. I think C++ is now coming into it's own and it sucked in the past much more. D is now in it's sucky period IMO, and may have it's day in the future. Time will tell. When I say "C++ is crappy", I mean "within today's context, and moving forward from here". Tomorrow is surely something else, probably not D, IMO, but today is all C++. I'm certainly aware of all that, and I do understand. But the question here wasn't "Do you think OTHER people feel language X is suitable for serious work?" It was "Do YOU think language X is suitable for serious work?" I don't doubt other people would disagree with me (especially people who haven't used D, and even probably some who have), but my own answer is "Yes, I think D is suitable for such projects, and in such a situation, yes, I would be willing to put my money where my mouth is." Ha! I inadvertently just answered those questions. Well, I guess you know what I think now (not that I was going to hide it).

"Nick Sabalausky" writes "Xavier" <xman nospam.net> wrote in message news:j51jsp$2lln$2 digitalmars.com... "Nick Sabalausky" <a a.a> wrote in message news:j51h52$2h0e$1 digitalmars.com... "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, Oh, definitely. But what I meant was that good D programmers can be cultivated. People can learn to be good at D. And while the same might *technically* be true of C++, the curve is so steep that it may as well be "what's out there is what's out there". It's, more or less, a non-renewable resource. It's not nearly as "steep" as it used to be, for C++, the tools, the techniques, the documentation, the users have matured and one need not struggle through everything on one's own anymore while learning it, but rather just go look up or ask for the answer, and it is still improving. Sure, if one exploits every "stupid template trick" and similarly with the other language features, then you will have "steep", but it is quite tractable these days if one isn't overzealous and able to separate all the jabber about "metaprogramming" and the like from the meat of the language. It will always have its warts, but D has many of the same ones. In other words, "C++ is easy^H^H^H^Hless hard than it used to be, as long as you don't use any of the advanced features that are already trivial in D anyway." I realize I've said this other times in the past, but I find that the compiler bugs in DMD are much less severe than the language deficiencies of a fully-bug-free C++ implementation. That's an interesting, if not odd, statement considering that C++ are more alike than they are different. I don't understand what you're saying here. Did you mean "D and C++ are more alike than different", or "C++ implementations are more alike than are different". Either way, it doesn't make much sense. Plus there's the idea of investing in the future to keep in mind: It's like the old quote: "I may be fat, but you're stupid. I can excersise and diet, but stupid will always be stupid." The truth of the matter is, though, that she won't exercise to any significant degree and has been on a diet her whole life and her weight has continually increased. On top of that, the fact that one can study, research and learn escapes the fat dumb blonde bimbo because she indeed is stupid, and that's why her "dieting" causes her to gain weight instead of lose it. You've just completely broken the analogy because D's bugs *DO* get fixed. And they're getting fixed rather quickly now, too. D may have some bugs, but investing the effort to deal with them will lead to further improvements. Dealing with C++'s problems, OTOH, will hardly do a damn thing. Again, I find that a curious statement for reason noted. The language names even fit together: C/C++/D. There is no denying that they are all related. Just look at those noses! C'mon! Umm, yea, they're related. So what? Don't tell me you're trying to imply that just because they're related they're inherently equal in everything but implementation. Sure, a few things can be mitigated somewhat, such as the C++0x^H^H1x^H^H2x^H^H3x improvents. But in general, investing the effort to deal with C++'s shortcomings won't lead to significant improvements - it *can't* because it's constrained by its existing legacy design (not that that won't eventually happen to D, too, but D is one generation past C++). One generation away, but still the same family. So what? Ie., D may be buggy, but C++ is crappy. Bugs can be fixed, but crappy will always be crappy. All adolescents conflict with their parents and say things like that. When D grows up, the D++ or E kids will be maligning D and then D will remember back how it was just the same when it was just a youngster. Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. FWIW, I had been a huge fan of C++ for many years and used it extensively ('course, that was quite awhile ago now...). And I *do* think it was a great language back in it's time. I just think that time is long since past. I think C++ is now coming into it's own and it sucked in the past much more. D is now in it's sucky period IMO, and may have it's day in the future. Time will tell. Well, like I've said, I'd rather something with better language design and a few implementation worts, than something with inferior language design and perfect implementation. When I say "C++ is crappy", I mean "within today's context, and moving forward from here". Tomorrow is surely something else, probably not D, IMO, but today is all C++. I'm certainly aware of all that, and I do understand. But the question here wasn't "Do you think OTHER people feel language X is suitable for serious work?" It was "Do YOU think language X is suitable for serious work?" I don't doubt other people would disagree with me (especially people who haven't used D, and even probably some who have), but my own answer is "Yes, I think D is suitable for such projects, and in such a situation, yes, I would be willing to put my money where my mouth is." Ha! I inadvertently just answered those questions. Well, I guess you know what I think now (not that I was going to hide it). You mean that you're just here to troll?

writes Josh Simmons On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalausky <a a.a> wrote: Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? No I believe the implication is that absolute quality is so absurdly impossible to define that it's somewhat irrelevant to even contemplate it. And it's certainly overly simplistic to consider it without putting it in the context of a given problem. Yes C++ is crap, but so is D, they're both crappy in their own ways, to suggest otherwise is to assume that you're so much more intelligent than all that have come before you that you've managed to create a perfect product when all else have failed. To make analogy, it's like saying that OOP is inherently better than any paradigm before it. Ultimately though the issue is that C++'s crap is well explored and known, D's crap is significantly less so. Whether this is an issue for you depends entirely on your context.

writes Timon Gehr On 09/17/2011 10:57 AM, Josh Simmons wrote: On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalausky<a a.a> wrote: Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? No I believe the implication is that absolute quality is so absurdly impossible to define that it's somewhat irrelevant to even contemplate it. And it's certainly overly simplistic to consider it without putting it in the context of a given problem. Well, my pragmatic and simplistic definition of language quality is how fast work is done using that particular language. And in my experience I get hella lot of more work done in less time in D. Yes C++ is crap, but so is D, they're both crappy in their own ways, What matters is the amount of crap. And D wins that game. to suggest otherwise is to assume that you're so much more intelligent than all that have come before you that you've managed to create a perfect product when all else have failed. D has the advantage of hindsight. One is always more intelligent afterwards, so assuming that one knows more than the ones before is realistic. That is how progress works. To make analogy, it's like saying that OOP is inherently better than any paradigm before it. Ultimately though the issue is that C++'s crap is well explored and known, D's crap is significantly less so. Whether this is an issue for you depends entirely on your context. Exploring crap is lost time. (and you stink afterwards, ftw!) If a language forces you to explore it's crap well to save your legs from being blown off, that is quite poor imho. You have to know what _works_.

writes "Xavier" Timon Gehr wrote: On 09/17/2011 10:57 AM, Josh Simmons wrote: On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalausky<a a.a> wrote: Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? No I believe the implication is that absolute quality is so absurdly impossible to define that it's somewhat irrelevant to even contemplate it. And it's certainly overly simplistic to consider it without putting it in the context of a given problem. Well, my pragmatic and simplistic definition of language quality is Oh curb it already.

Timon Gehr <timon.gehr gmx.ch> Timon Gehr writes On 09/18/2011 05:41 AM, Xavier wrote: Timon Gehr wrote: On 09/17/2011 10:57 AM, Josh Simmons wrote: On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalausky<a a.a> wrote: Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? No I believe the implication is that absolute quality is so absurdly impossible to define that it's somewhat irrelevant to even contemplate it. And it's certainly overly simplistic to consider it without putting it in the context of a given problem. Well, my pragmatic and simplistic definition of language quality is Oh curb it already. The only difference between that definition and most of the contents of your posts in this thread is that it actually introduces itself as being maybe too simplistic and therefore possibly not appropriate for a given situation. That is a strength, not a weakness. Please think before you post.

"Xavier" <xman nospam.net> "Xavier" writes "Josh Simmons" <simmons.44 gmail.com> wrote in message news:mailman.2925.1316249875.14074.digitalmars-d puremagic.com... On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalausky <a a.a> wrote: Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? No I believe the implication is that absolute quality is so absurdly impossible to define that it's somewhat irrelevant to even contemplate it. And it's certainly overly simplistic to consider it without putting it in the context of a given problem. Yes C++ is crap, but so is D, they're both crappy in their own ways, to suggest otherwise is to assume that you're so much more intelligent than all that have come before you that you've managed to create a perfect product when all else have failed. To make analogy, it's like saying that OOP is inherently better than any paradigm before it. Ultimately though the issue is that C++'s crap is well explored and known, D's crap is significantly less so. Whether this is an issue for you depends entirely on your context. See Nick, I'm not the only one thinking it.

writes J Arrizza 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

"Xavier" <xman nospam.net> "Xavier" writes J Arrizza wrote: Hmmm. If $100M was on the line, the project code base must be extremely large. Correct? Hello. Next!

"Xavier" <xman nospam.net> "Xavier" writes "Nick Sabalausky" <a a.a> wrote in message news:j51mq9$2r1t$1 digitalmars.com... "Xavier" <xman nospam.net> wrote in message news:j51jsp$2lln$2 digitalmars.com... "Nick Sabalausky" <a a.a> wrote in message news:j51h52$2h0e$1 digitalmars.com... "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, Oh, definitely. But what I meant was that good D programmers can be cultivated. People can learn to be good at D. And while the same might *technically* be true of C++, the curve is so steep that it may as well be "what's out there is what's out there". It's, more or less, a non-renewable resource. It's not nearly as "steep" as it used to be, for C++, the tools, the techniques, the documentation, the users have matured and one need not struggle through everything on one's own anymore while learning it, but rather just go look up or ask for the answer, and it is still improving. Sure, if one exploits every "stupid template trick" and similarly with the other language features, then you will have "steep", but it is quite tractable these days if one isn't overzealous and able to separate all the jabber about "metaprogramming" and the like from the meat of the language. It will always have its warts, but D has many of the same ones. In other words, "C++ is easy^H^H^H^Hless hard than it used to be, as long as you don't use any of the advanced features that are already trivial in D anyway." No, but rather that most programmers don't know how to program yet and they think they need those things all the time. I realize I've said this other times in the past, but I find that the compiler bugs in DMD are much less severe than the language deficiencies of a fully-bug-free C++ implementation. That's an interesting, if not odd, statement considering that C++ are more alike than they are different. I don't understand what you're saying here. Did you mean "D and C++ are more alike than different", or "C++ implementations are more alike than are different". Either way, it doesn't make much sense. The first one. Plus there's the idea of investing in the future to keep in mind: It's like the old quote: "I may be fat, but you're stupid. I can excersise and diet, but stupid will always be stupid." The truth of the matter is, though, that she won't exercise to any significant degree and has been on a diet her whole life and her weight has continually increased. On top of that, the fact that one can study, research and learn escapes the fat dumb blonde bimbo because she indeed is stupid, and that's why her "dieting" causes her to gain weight instead of lose it. You've just completely broken the analogy because D's bugs *DO* get fixed. And they're getting fixed rather quickly now, too. To be honest, I was just spouting on, and having fun with, the phrase and not it's applicability to anything in this thread. D may have some bugs, but investing the effort to deal with them will lead to further improvements. Dealing with C++'s problems, OTOH, will hardly do a damn thing. Again, I find that a curious statement for reason noted. The language names even fit together: C/C++/D. There is no denying that they are all related. Just look at those noses! C'mon! Umm, yea, they're related. So what? Don't tell me you're trying to imply that just because they're related they're inherently equal in everything but implementation. Ah, see now you're backing down. Now you are just trying to prove unequality rather than significant difference. Sure, a few things can be mitigated somewhat, such as the C++0x^H^H1x^H^H2x^H^H3x improvents. But in general, investing the effort to deal with C++'s shortcomings won't lead to significant improvements - it *can't* because it's constrained by its existing legacy design (not that that won't eventually happen to D, too, but D is one generation past C++). One generation away, but still the same family. So what? Ie., D may be buggy, but C++ is crappy. Bugs can be fixed, but crappy will always be crappy. All adolescents conflict with their parents and say things like that. When D grows up, the D++ or E kids will be maligning D and then D will remember back how it was just the same when it was just a youngster. Are you seriously trying say that that implies each successive one is inherently no better than the previous? I was alluding to the fact that you are overstating the significance of the difference between the two languages. That is to say that the differences are rather "cosmetic" more than they are meaningful. Oh, in a few areas, sure, there are differences, but overall, "same old stuff". If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll? I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. FWIW, I had been a huge fan of C++ for many years and used it extensively ('course, that was quite awhile ago now...). And I *do* think it was a great language back in it's time. I just think that time is long since past. I think C++ is now coming into it's own and it sucked in the past much more. D is now in it's sucky period IMO, and may have it's day in the future. Time will tell. Well, like I've said, I'd rather something with better language design and a few implementation worts, than something with inferior language design and perfect implementation. Yeah, yeah.. OK "fan boy". ;) When I say "C++ is crappy", I mean "within today's context, and moving forward from here". Tomorrow is surely something else, probably not D, IMO, but today is all C++. I'm certainly aware of all that, and I do understand. But the question here wasn't "Do you think OTHER people feel language X is suitable for serious work?" It was "Do YOU think language X is suitable for serious work?" I don't doubt other people would disagree with me (especially people who haven't used D, and even probably some who have), but my own answer is "Yes, I think D is suitable for such projects, and in such a situation, yes, I would be willing to put my money where my mouth is." Ha! I inadvertently just answered those questions. Well, I guess you know what I think now (not that I was going to hide it). You mean that you're just here to troll?

writes "Xavier" "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills?

writes Jonathan M Davis On Saturday, September 17, 2011 02:26:12 Xavier wrote: "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? The language itself is superior. It's the implementation which has issues, though those have been being resolved at a fairly fast pace of late. - Jonathan M Davis

writes "Xavier" "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2923.1316247041.14074.digitalmars-d puremagic.com... On Saturday, September 17, 2011 02:26:12 Xavier wrote: "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? The language itself is superior. A family of languages goes from "crappy" to "superior" in one generation? Umm, I don't think so, "fan boy". ;) It's the implementation which has issues, though those have been being resolved at a fairly fast pace of late. It's not just that, though I believe that you think that.

writes Jonathan M Davis On Saturday, September 17, 2011 03:17:27 Xavier wrote: "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2923.1316247041.14074.digitalmars-d puremagic.com... The language itself is superior. A family of languages goes from "crappy" to "superior" in one generation? Umm, I don't think so, "fan boy". ;) ??? I didn't say anything about the family of languages. I said that D, as a language, is superior to C++. - Jonathan M Davis

writes "Xavier" "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2924.1316247900.14074.digitalmars-d puremagic.com... On Saturday, September 17, 2011 03:17:27 Xavier wrote: "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2923.1316247041.14074.digitalmars-d puremagic.com... The language itself is superior. A family of languages goes from "crappy" to "superior" in one generation? Umm, I don't think so, "fan boy". ;) ??? I didn't say anything about the family of languages. I know you didn't, I did. Read my post in response to Nick's post. I said that D, as a language, is superior to C++. Yeah, yeah... OK "fan boy". ;)

Timon Gehr <timon.gehr gmx.ch> Timon Gehr writes On 09/17/2011 10:40 AM, Xavier wrote: "Jonathan M Davis"<jmdavisProg gmx.com> wrote in message news:mailman.2924.1316247900.14074.digitalmars-d puremagic.com... On Saturday, September 17, 2011 03:17:27 Xavier wrote: "Jonathan M Davis"<jmdavisProg gmx.com> wrote in message news:mailman.2923.1316247041.14074.digitalmars-d puremagic.com... The language itself is superior. A family of languages goes from "crappy" to "superior" in one generation? Umm, I don't think so, "fan boy". ;) ??? I didn't say anything about the family of languages. I know you didn't, I did. Read my post in response to Nick's post. I said that D, as a language, is superior to C++. Yeah, yeah... OK "fan boy". ;) Don't feed the troll.

"Nick Sabalausky" writes "Xavier" <xman nospam.net> wrote in message news:j51jsp$2lln$1 digitalmars.com... "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? In both this and your other post, you're conflating the notions of the "language quality" vs "implementation quality". The two are not the same. Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So no, it's NOT a contradiction that D can be a better language while still having implementation issues.

writes "Xavier" "Nick Sabalausky" <a a.a> wrote in message news:j51m0l$2prg$1 digitalmars.com... "Xavier" <xman nospam.net> wrote in message news:j51jsp$2lln$1 digitalmars.com... "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? In both this and your other post, you're conflating the notions of the "language quality" vs "implementation quality". The two are not the same. They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language "quality" issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like "D is better than the POS that C++ is". To be markedly different from C++, D would have to be thought of as being in a different category than "which is the better POS?", but of course it cannot, for it comes from the same family, "one generation newer than C++". Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas. An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that. And notice too that for software development that is not that, "intellisense" dramatically reduces the number of times a programmer hits the compile button. That one thing is not as big an issue and certainly it pales in comparison to other language design flaws, which C++ and D both share. So no, it's NOT a contradiction that D can be a better language while still having implementation issues. Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship.

Timon Gehr <timon.gehr gmx.ch> Timon Gehr writes On 09/17/2011 11:17 AM, Xavier wrote: "Nick Sabalausky"<a a.a> wrote in message news:j51m0l$2prg$1 digitalmars.com... "Xavier"<xman nospam.net> wrote in message news:j51jsp$2lln$1 digitalmars.com... "Jonathan M Davis"<jmdavisProg gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d puremagic.com... I definitely prefer D to C++, but I honestly think that your hatred of C++ (which you have expressed on several occasions) clouds your judgement on the matter. Many, many programmers are fine with C++, and while many programmers may like C++ to be improved or would like a language that's similar to C++ but without as many warts, that doesn't mean that they're going to be in a hurry to try out D. And many, many of the people who have problems with C++ use languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills? In both this and your other post, you're conflating the notions of the "language quality" vs "implementation quality". The two are not the same. They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language "quality" issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like "D is better than the POS that C++ is". To be markedly different from C++, D would have to be thought of as being in a different category than "which is the better POS?", but of course it cannot, for it comes from the same family, "one generation newer than C++". Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas. An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that. And notice too that for software development that is not that, "intellisense" dramatically reduces the number of times a programmer hits the compile button. I don't need intellisense, I'm fine with emacs. And compiling D code is usually so much faster than compiling C++ code that it is not even funny. Recompiling is not costly at all. That one thing is not as big an issue and certainly it pales in comparison to other language design flaws, which C++ and D both share. Exactly which flaws are you talking about? Either get concrete so that your statements can be discussed and someone gets smarter in the process or stop making noise please. So no, it's NOT a contradiction that D can be a better language while still having implementation issues. Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). Well, nobody wants to convince you that D and C++ don't belong to the same category. (as far language design goes). Whatever that means to you. But talking is worthless indeed. All your arguments are based on the wrong assumption that C++ and D are basically equal. You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. Hating C++ is not a requirement for liking D better. Actually writing some lines of D code on the other hand, is. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship. If I want to reach an island, I usually don't swim. I take a ship that gets me there.

"Nick Sabalausky" <a a.a> "Nick Sabalausky" writes "Xavier" <xman nospam.net> wrote in message news:j51p5q$2utg$1 digitalmars.com... "Nick Sabalausky" <a a.a> wrote in message news:j51m0l$2prg$1 digitalmars.com... In both this and your other post, you're conflating the notions of the "language quality" vs "implementation quality". The two are not the same. They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language "quality" issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like "D is better than the POS that C++ is". To be markedly different from C++, D would have to be thought of as being in a different category than "which is the better POS?", but of course it cannot, for it comes from the same family, "one generation newer than C++". Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas. What you're ultimately saying is that if a guitar has a crappy first and second string (and therefore sounds lousy), then you also have to replace the other four strings, the pickups, the head, the body, the amp, the neck and the carrying case to make it sound good again. Replacing the two crappy strings won't be enough to make it sound significantly better. What you're missing is that a minority portion *can* ruin a whole. If you consider D and C++ to be mostly the same, then C++ is crappy because of, what you're perceiving to be, a minority subset of it's design. D cuts out the cancer and saves the whole. Your notion that a big imporvement requires a big change is just plain false. An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that. You know perfectly well those were just examples. And notice too that for software development that is not that, "intellisense" dramatically reduces the number of times a programmer hits the compile button. That one thing is not as big an issue and certainly it pales in comparison to other language design flaws, which C++ and D both share. 1. IDE features are not substitutes for language improvement. 2. Such features don't end up in a IDE "for free". There's cost associated with actually putting them in there for a given language. You're not factoring that in. Additionally, this also implies that not everyone always has such features available. So no, it's NOT a contradiction that D can be a better language while still having implementation issues. Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship. Yes, because if one boat starts sinking, they're all about to start sinking... And if you felt sick due to kidney failure, you'd insist that replacing the kidney will just make you slightly less sick. So you'd insist the doctor also replace your heart, your hip and your leg, fuse your spine, perform brain surgery, die your hair, and give you glasses, dentures and a facelift...

writes Andrei Alexandrescu On 9/17/11 4:17 CDT, Xavier wrote: Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship. One's favorite language has most to do with a handful of fundamental dimensions (dominant paradigm(s), approach to typing, look and feel, regard to efficiency, connection to problem domain vs. machine, and a few more). A coworker of mine, for example, doesn't mind a speed penalty of 2-5x, likes modeling power and semantic cleanliness, and is okay with some amount of code duplication. His favorite language is OCaml, and I'd probably choose the same if I had the same preferences. For those who want at the same time like low-level access, modeling power, generic programming, and efficiency, OCaml wouldn't rank high in the list of preferences, and there wouldn't be many games in town. In your metaphor, swimming from a ship to an island would entail trading something that C++ offers for something it can't offer - which is fine. If, on the other hand, you'd rather keep to the fundamentals above, D is arguably a better language. One other thing is flexibility once the choice has been made. Python is a great Python but an awful C++, not to mention the converse. D, on the other hand, is arguably a much better C++ and also a pretty good Python. Andrei

renoX <renozyx gmail.com> renoX writes Python is a great Python but an awful C++, not to mention the converse. D, on the other hand, is arguably a much better C++ and also a pretty good Python. "Pretty good" as in pretty bad for integer operations where Python3 use "big int" and D silently corrupt your data in case of overflow like C/C++ if memory serves. BR, renoX

Lutger Blijdestijn <lutger.blijdestijn gmail.com> Lutger Blijdestijn writes Jonathan M Davis wrote: On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote: People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. It's a _lot_ easier to find good C++ programmers than good D programmers, and I suspect that given the current issues with the GC, if you were working on a AAA game, then you'd probably want the folks doing it to be good C/C++ programmers so that they would know how to do what needed doing when they can't use the GC or most of the standard libraries. For projects where performance isn't quite as critical, then D stands a much better chance of working. It _is_ easier to learn and has some definite advantages over C++. Any programmer should be able to learn any language on the job. This doesn't make sense for small projects, but for larger projects the overhead can be small enough to warrant hiring competent programmers without any knowledge of the language. D is familiar enough for C++/C#/Java programmers to pick it up quickly. Especially for C++ programmers, given a sufficiently large timescale, it is not unthinkable that all time spent learning is recuperated by the productivity and scalability gains. I just cannot image a good C++ programmer having difficulty picking up D quickly.

writes Peter Alexander On 17/09/11 6:53 AM, Nick Sabalausky wrote: "Peter Alexander"<peter.alexander.au gmail.com> wrote in message For example, if the job was to produce a AAA video game that ran on PC, PS3 and XBox 360, I'm sure you could *do it* with D if you paid people to develop the compiler tech and tools to produce PowerPC code and interface with all MS's and Sony's libraries and tools. But would you? People who are *good* at C++ are hard to find, and even harder to cultivate. And that's never going to change. It's a fundamental limitation of the langauge (at least until the Vulcans finally introduce themselves to us). But D's a lot easier for people to become good at. You don't need people that are especially good at C++. You don't need to know metaprogramming or generic programming or the intricacies of templates to ship a product. Just look at the DMD compiler: there's no advanced C++ in there at all. It still works. And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. I am unaware of any distributed, incremental build systems for D, so I see no particular speed advantage to using D (certainly not orders of magnitude anyway). I'm sure there are smaller reasons too, but I'm convinced the primary reason why AAA game dev is C++ instead of D is ultimately because of inertia, not the languages themselves, or even the tools (If the AAA game dev industry genuinely wanted to be using D, you can bet that any tools they needed would get made). Tools are not free. Don't assume just because a company is large that it has unlimited funds. Creating tools, converting libraries all take lots of time and money that have to be justified. I work at a very large game studio and I can assure you that I would *never* be able to justify using D for a project. Even if all our code magically transformed into D, and all our programmers knew D, I still wouldn't be able to justify the creation of all the necessary tools and dev systems to do something that we can already do.

writes Andrei Alexandrescu On 9/17/11 10:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. Then Facebook would love your application (I'm not kidding; send me private email if interested). We have a dedicated team of bright engineers who worked valiantly on this (I also collaborated), and a dedicated server farm. Compile times are still a huge bottleneck. Andrei

writes Peter Alexander On 17/09/11 4:28 PM, Andrei Alexandrescu wrote: On 9/17/11 10:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. Then Facebook would love your application (I'm not kidding; send me private email if interested). We have a dedicated team of bright engineers who worked valiantly on this (I also collaborated), and a dedicated server farm. Compile times are still a huge bottleneck. Andrei It's not my application. We use Incredibuild: http://www.xoreax.com/ And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/

writes Andrei Alexandrescu On 09/17/2011 12:55 PM, Peter Alexander wrote: On 17/09/11 4:28 PM, Andrei Alexandrescu wrote: On 9/17/11 10:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. Then Facebook would love your application (I'm not kidding; send me private email if interested). We have a dedicated team of bright engineers who worked valiantly on this (I also collaborated), and a dedicated server farm. Compile times are still a huge bottleneck. Andrei It's not my application. I meant employment application. We use Incredibuild: http://www.xoreax.com/ Is it available on Linux? And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/ That thing when you concatenate everything to be compiled, right? We don't do that although the technique is known. I'll ask why. Off the top of my head, incremental compilation is difficult. I also wonder how the whole thing can be distributed if it's all in one file. Thanks, Andrei

Peter Alexander <peter.alexander.au gmail.com> Peter Alexander writes On 17/09/11 8:52 PM, Andrei Alexandrescu wrote: On 09/17/2011 12:55 PM, Peter Alexander wrote: On 17/09/11 4:28 PM, Andrei Alexandrescu wrote: On 9/17/11 10:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: And then there's the enurmous savings in build times alone. Full recompiles of AAA C++ games are known to take upwards of a full day (not sure whether that's using a compile farm, but even if it is, D could still cut down on compile farm expenses, or possibly even the need for one). This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines. Then Facebook would love your application (I'm not kidding; send me private email if interested). We have a dedicated team of bright engineers who worked valiantly on this (I also collaborated), and a dedicated server farm. Compile times are still a huge bottleneck. Andrei It's not my application. I meant employment application. We use Incredibuild: http://www.xoreax.com/ Is it available on Linux? From what I can tell from the website, it's Windows only. And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/ That thing when you concatenate everything to be compiled, right? We don't do that although the technique is known. I'll ask why. Off the top of my head, incremental compilation is difficult. I also wonder how the whole thing can be distributed if it's all in one file. You don't need to concatenate everything into a single file. Just put maybe 50 source files per unity file (group ones that #include common headers) and then compile all the unity files separately. That way you can distribute individual unity files, and it also means that you don't have to rebuild the entire solution when changing a single source file. It's a bit of a balancing act getting the right number of unity files.

writes "Vladimir Panteleev" On Sat, 17 Sep 2011 20:55:38 +0300, Peter Alexander <peter.alexander.au gmail.com> wrote: And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/ I've always wondered if the overhead that unity builds are supposed to reduce was mainly because of all the build tools which force the OS to flush intermediate files to disk. Has anyone compared the performance advantages of using unity builds versus building everything on a RAM drive? -- Best regards, Vladimir mailto:vladimir thecybershadow.net

Peter Alexander <peter.alexander.au gmail.com> Peter Alexander writes On 17/09/11 8:59 PM, Vladimir Panteleev wrote: On Sat, 17 Sep 2011 20:55:38 +0300, Peter Alexander <peter.alexander.au gmail.com> wrote: And I'm sure you know what unity builds are. For those that don't: http://buffered.io/2007/12/10/the-magic-of-unity-builds/ I've always wondered if the overhead that unity builds are supposed to reduce was mainly because of all the build tools which force the OS to flush intermediate files to disk. Has anyone compared the performance advantages of using unity builds versus building everything on a RAM drive? I have no idea if anyone has done that comparison. That's certainly not the only advantage though. If you went with the single unity file approach then it means that each header needs to only be parsed once. It also means that unique template instantiations are only emitted once, making things easier for the linker. I once measured that it takes GCC 30ms on my laptop to emit an std::sort of an int array.

writes Adam D. Ruppe Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? My slowest D compile except my one attempt into qtd is about 30,000 lines of template using code that takes about 5 seconds on my computer. (I compile and link it all at once) I could see this getting annoying if it continued to scale that way to 3 million, but that's still the exception in my experience: my typical D program builds in under one second, including a 14,000 line hobby game.

writes Josh Simmons On Sun, Sep 18, 2011 at 1:32 AM, Adam D. Ruppe <destructionator gmail.com> wrote: Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? My slowest D compile except my one attempt into qtd is about 30,000 lines of template using code that takes about 5 seconds on my computer. (I compile and link it all at once) I could see this getting annoying if it continued to scale that way to 3 million, but that's still the exception in my experience: my typical D program builds in under one second, including a 14,000 line hobby game. As a general rule I think, most things don't scale linearly, they scale considerably worse.

Adam D. Ruppe <destructionator gmail.com> Adam D. Ruppe writes Josh Simmons wrote: As a general rule I think, most things don't scale linearly, they scale considerably worse. Let's try something: === import std.file; import std.conv; import std.string; void main() { string m; foreach(i; 0 .. 1000) { string code; foreach(a; 0 .. 1000) { code ~= format(q{ int someGlobal%d; void someFunction%d() { someGlobal%d++; } }, a, a, a); } std.file.write("file" ~ to!string(i) ~ ".d", code); m ~= "import file" ~ to!string(i) ~ ";"; } std.file.write("main.d", m ~ " void main() {} "); } === $ ./generate $ wc *.d 5000000 7001004 83684906 total $ time dmd *.d Segmentation fault real 0m29.915s user 0m26.208s sys 0m3.684s Holy shit, 3.6 GB of memory used! Aaaand segmentation fault. OK, something's not good here :-P Let's try this: $ time ../dmd2/linux/bin64/dmd *.d real 0m45.363s user 0m26.009s sys 0m14.193s About 6 GB total memory used at the peak. Wow. I never thought I'd actually use that much ram (but it was cheap). $ ls -lh *.o -rw-r--r-- 1 me users 371M 2011-09-17 12:40 file0.o For some reason, there's no executable... $ time ld file0.o ../dmd2/linux/lib64/libphobos2.a -lm -lpthread ld: warning: cannot find entry symbol _start; defaulting to 0000000000400f20 real 0m10.439s user 0m9.304s sys 0m0.915s $ ls -lh ./a.out -rwxr-xr-x 1 me users 102M 2011-09-17 12:43 ./a.out Wow. Anyway, one minute to compile 5,000,000 lines of (bullshit) code isn't really bad. It took a lot of memory, but that's not a dealbreaker - I got this 8 gb dirt cheap, and the price has gone down even more since then. Worst case, we can just throw more hardware at it. This code is nothing fancy, of course. Now, what about an incremental build. $ echo 'rm *.o; for i in *.d; do dmd -c ; done; dmd *.o' > build $ time bash build waiting... lots of hard drive activity here. (BTW, I realize in a real build, you could do a lot of this in parallel, so this isn't really a fair scenario. I'm just curious how it will turn out.) ld is running now. I guess dmd did it's thing in about one minute Anyway, it's complete: $ time bash build.sh rm: cannot remove `*.o': No such file or directory real 1m44.632s user 1m17.358s sys 0m10.275s Two minutes for compile+link incrementally. The memory usage never became significant. $ ls -l file0 -rwxr-xr-x 1 me users 214M 2011-09-17 12:50 file0 This is probably double unrealistic since I didn't have any of the modules import other modules. But, I did feed 5,000,000 lines of code spread over 1,000 modules to the D compiler, and it managed to work in a fairly reasonable time - one minute is decent. Of course, if you bring in fancier things than this trivial example, who knows.

writes Peter Alexander On 17/09/11 4:32 PM, Adam D. Ruppe wrote: Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? Nope. I use some parts of the standard library, not much of it though. I also use Derelict, but again, not much of it. I'm talking about a -release -inline -O build btw. For a normal build it's only 1.7 seconds.

writes Adam D. Ruppe Ah, that explains it. I usually don't use the -O switch.

writes "Marco Leise" Am 17.09.2011, 20:01 Uhr, schrieb Adam D. Ruppe <destructionator gmail.com>: Ah, that explains it. I usually don't use the -O switch. During development when you recompile several times an hour, you really don't need -O either. For my hobby projects I usually set up the IDE with a compile command without -O and place a Makefile in the directory that has optimizations enabled. Sure, there are times when you run performance tests, but they aren't the usual case, so I think it is fair to compare compiles without optimizations in this context.

writes Peter Alexander On 17/09/11 7:52 PM, Marco Leise wrote: Am 17.09.2011, 20:01 Uhr, schrieb Adam D. Ruppe <destructionator gmail.com>: Ah, that explains it. I usually don't use the -O switch. During development when you recompile several times an hour, you really don't need -O either. For my hobby projects I usually set up the IDE with a compile command without -O and place a Makefile in the directory that has optimizations enabled. Sure, there are times when you run performance tests, but they aren't the usual case, so I think it is fair to compare compiles without optimizations in this context. I suppose that's true for most people, but not for games developers. When testing changes, you need the game to be running at interactive framerates, and it's very difficult to achieve that in a debug build, so we generally always run optimized, and just use MSVC++'s #pramga optimize(off, "") directive to unoptimize specific sections of code for debugging. To be fair, my hobby project still runs fast without optimizations, but I definitely need to repeatedly compile with optimizations on when performance tuning.

writes "Marco Leise" Am 17.09.2011, 22:33 Uhr, schrieb Peter Alexander <peter.alexander.au gmail.com>: On 17/09/11 7:52 PM, Marco Leise wrote: Am 17.09.2011, 20:01 Uhr, schrieb Adam D. Ruppe <destructionator gmail.com>: Ah, that explains it. I usually don't use the -O switch. During development when you recompile several times an hour, you really don't need -O either. For my hobby projects I usually set up the IDE with a compile command without -O and place a Makefile in the directory that has optimizations enabled. Sure, there are times when you run performance tests, but they aren't the usual case, so I think it is fair to compare compiles without optimizations in this context. I suppose that's true for most people, but not for games developers. When testing changes, you need the game to be running at interactive framerates, and it's very difficult to achieve that in a debug build, so we generally always run optimized, and just use MSVC++'s #pramga optimize(off, "") directive to unoptimize specific sections of code for debugging. To be fair, my hobby project still runs fast without optimizations, but I definitely need to repeatedly compile with optimizations on when performance tuning. May I ask how much slower the frame rate is with the debug build? I would think of certain modules like physics or vegetation to be in precompiled external libraries (or do you use source code versions?) and the graphic card doing a lot of work. Also I remember when some game developer said a while back "we are not cpu bound at all". Has that changed again? Or is it maybe because your project has not been optimized yet? Or is it simply that you are developing for the next generation of hardware? My definition of interactive frame rate starts at ~20 FPS I guess, sounds like it would be easy to achieve. Then again the only game I ever finished was a random maze pac man clone with 16 colors Windows .ico graphics *g*

Peter Alexander <peter.alexander.au gmail.com> Peter Alexander writes On 18/09/11 8:59 AM, Marco Leise wrote: Am 17.09.2011, 22:33 Uhr, schrieb Peter Alexander <peter.alexander.au gmail.com>: On 17/09/11 7:52 PM, Marco Leise wrote: Am 17.09.2011, 20:01 Uhr, schrieb Adam D. Ruppe <destructionator gmail.com>: Ah, that explains it. I usually don't use the -O switch. During development when you recompile several times an hour, you really don't need -O either. For my hobby projects I usually set up the IDE with a compile command without -O and place a Makefile in the directory that has optimizations enabled. Sure, there are times when you run performance tests, but they aren't the usual case, so I think it is fair to compare compiles without optimizations in this context. I suppose that's true for most people, but not for games developers. When testing changes, you need the game to be running at interactive framerates, and it's very difficult to achieve that in a debug build, so we generally always run optimized, and just use MSVC++'s #pramga optimize(off, "") directive to unoptimize specific sections of code for debugging. To be fair, my hobby project still runs fast without optimizations, but I definitely need to repeatedly compile with optimizations on when performance tuning. May I ask how much slower the frame rate is with the debug build? I would think of certain modules like physics or vegetation to be in precompiled external libraries (or do you use source code versions?) and the graphic card doing a lot of work. My D project is between 1.5 and 2.0x slower in debug builds vs. release. At work it's about 4x slower on consoles in full debug vs. full opt and 3x slower vs. partial optimisation. Also I remember when some game developer said a while back "we are not cpu bound at all". Has that changed again? Or is it maybe because your project has not been optimized yet? Or is it simply that you are developing for the next generation of hardware? It depends on the game, and of course what settings the player is playing at. Playing at lowest graphics fidelity you will probably always be CPU bound and at highest fidelity you will always be GPU bound. My definition of interactive frame rate starts at ~20 FPS I guess, sounds like it would be easy to achieve. Then again the only game I ever finished was a random maze pac man clone with 16 colors Windows .ico graphics *g* Well most consoles games run at 30fps these days, so for debug builds you are often dropping below 20, or even 10 fps. It's not just the frame rate either, we have a lot of assets to load in and they all take longer to load in non-optimized builds, which increases the time it takes to iterate on changes.

writes Don On 17.09.2011 19:58, Peter Alexander wrote: On 17/09/11 4:32 PM, Adam D. Ruppe wrote: Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? Nope. I use some parts of the standard library, not much of it though. I also use Derelict, but again, not much of it. I'm talking about a -release -inline -O build btw. For a normal build it's only 1.7 seconds. I have a suspicion about what's causing this. The main loop of the optimiser has a O(n^^2) behaviour with consecutive comma expressions. -release -inline makes a large number of comma expressions (there doesn't need to be any in your code). I've seen n reach 200; maybe it gets even higher in your case. This isn't an intrinsic O(n^^2) algorithm, it would be pretty easy to fix, I think.

Peter Alexander <peter.alexander.au gmail.com> Peter Alexander writes On 19/09/11 11:27 PM, Don wrote: On 17.09.2011 19:58, Peter Alexander wrote: On 17/09/11 4:32 PM, Adam D. Ruppe wrote: Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? Nope. I use some parts of the standard library, not much of it though. I also use Derelict, but again, not much of it. I'm talking about a -release -inline -O build btw. For a normal build it's only 1.7 seconds. I have a suspicion about what's causing this. The main loop of the optimiser has a O(n^^2) behaviour with consecutive comma expressions. -release -inline makes a large number of comma expressions (there doesn't need to be any in your code). I've seen n reach 200; maybe it gets even higher in your case. This isn't an intrinsic O(n^^2) algorithm, it would be pretty easy to fix, I think. Ah ok, that makes sense. In the meantime, any tips for avoiding this? Would splitting up large functions help?

Dmitry Olshansky <dmitry.olsh gmail.com> Dmitry Olshansky writes On 20.09.2011 2:27, Don wrote: On 17.09.2011 19:58, Peter Alexander wrote: On 17/09/11 4:32 PM, Adam D. Ruppe wrote: Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? Nope. I use some parts of the standard library, not much of it though. I also use Derelict, but again, not much of it. I'm talking about a -release -inline -O build btw. For a normal build it's only 1.7 seconds. I have a suspicion about what's causing this. The main loop of the optimiser has a O(n^^2) behaviour with consecutive comma expressions. -release -inline makes a large number of comma expressions (there doesn't need to be any in your code). I've seen n reach 200; maybe it gets even higher in your case. This isn't an intrinsic O(n^^2) algorithm, it would be pretty easy to fix, I think. I have no solid facts to confirm this but I also noticed that combination of -O and -inline on my code does take few times longer to build then two builds with each of flags used separately. -- Dmitry Olshansky

"Steven Schveighoffer" <schveiguy yahoo.com> "Steven Schveighoffer" writes On Mon, 19 Sep 2011 18:27:29 -0400, Don <nospam nospam.com> wrote: On 17.09.2011 19:58, Peter Alexander wrote: On 17/09/11 4:32 PM, Adam D. Ruppe wrote: Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? Nope. I use some parts of the standard library, not much of it though. I also use Derelict, but again, not much of it. I'm talking about a -release -inline -O build btw. For a normal build it's only 1.7 seconds. I have a suspicion about what's causing this. The main loop of the optimiser has a O(n^^2) behaviour with consecutive comma expressions. -release -inline makes a large number of comma expressions (there doesn't need to be any in your code). I've seen n reach 200; maybe it gets even higher in your case. This isn't an intrinsic O(n^^2) algorithm, it would be pretty easy to fix, I think. While you're on speeding up compilation, here's another issue that causes dcollections unit tests to take 20 seconds to build, while building the release library takes less than a second: http://d.puremagic.com/issues/show_bug.cgi?id=4900 This was after Walter fixed a really bad performance bug where symbols were searched linearly. He says the same methodology (switch to hash table) should be used. I'm hoping this speeds compilation up to the point where the main bottleneck is i/o. Given how much percentage of compile time the linear searches take (at least in my case), this should bring down compile times significantly. I think this one should speed up phobos builds too, because it's definitely exacerbated by lots of template instantiations. -Steve

"Nick Sabalausky" <a a.a> "Nick Sabalausky" writes "Adam D. Ruppe" <destructionator gmail.com> wrote in message news:j52eia$133v$1 digitalmars.com... Peter Alexander wrote: In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. Curious, did you use a library like QtD? My slowest D compile except my one attempt into qtd is about 30,000 lines of template using code that takes about 5 seconds on my computer. (I compile and link it all at once) DDMD takes 1-2 minutes to build for me.

Walter Bright <newshound2 digitalmars.com> Walter Bright writes On 9/17/2011 8:08 AM, Peter Alexander wrote: I work at a very large game studio and I can assure you that I would *never* be able to justify using D for a project. Even if all our code magically transformed into D, and all our programmers knew D, I still wouldn't be able to justify the creation of all the necessary tools and dev systems to do something that we can already do. This is true in any industry that has a large investment in an existing technology. Eventually the pressure to make the change becomes overwhelming.

writes Sean Kelly On Sep 17, 2011, at 8:08 AM, Peter Alexander wrote: On 17/09/11 6:53 AM, Nick Sabalausky wrote: =20 And then there's the enurmous savings in build times alone. Full = recompiles of AAA C++ games are known to take upwards of a full day (not sure = whether that's using a compile farm, but even if it is, D could still cut = down on compile farm expenses, or possibly even the need for one). =20 This is false. You can easily build several million lines of code in = several minutes using unity files and distributed building. There need = not be any build farm expenses, the build machines can just be = everyone's dev machines. Linking can still be pretty time consuming. My last big project was = several million LOC broken into a tree of projects that all eventually = produced a handful of large applications. This was a originally SPARC = Solaris app so we couldn't spread the build across PCs, but rather built = in parallel on big fancy machines. When I started, a full build took = the better part of a work day, and before I left a full build was = perhaps 30 minutes (my memory is a bit fuzzy here, but that sounds like = a reasonable ballpark). The average level of parallelism was 10-20 = cores working on the build using make -j. I suppose it's worth = mentioning that building on Opteron was significantly faster, even using = fewer cores. The code used almost no templates, which is a significant = factor in total compile time. In contrast, my D hobby project at only a few thousand lines of code = already takes 11s to build and doesn't do any fancy metaprogramming or = use CTFE. I am unaware of any distributed, incremental build systems for = D, so I see no particular speed advantage to using D (certainly not = orders of magnitude anyway). My current project builds in 15 minutes on its current, ancient build = machine at work. Written in C. A full build on my PC is under 5 = minutes. Obviously, compile time isn't the only reason to choose D over = some other language though. I'm sure there are smaller reasons too, but I'm convinced the primary = reason why AAA game dev is C++ instead of D is ultimately because of = inertia, not the languages themselves, or even the tools (If the AAA game dev = industry genuinely wanted to be using D, you can bet that any tools they = needed would get made). =20 Tools are not free. Don't assume just because a company is large that = it has unlimited funds. Creating tools, 