www.digitalmars.com         C & C++   DMDScript  

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

reply Peter Alexander <peter.alexander.au gmail.com> writes:
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.
Sep 16 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 16 2011
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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?
Sep 16 2011
parent reply "Nick Sabalausky" <a a.a> 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.
Sep 16 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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 

uphill battle to truly become as relevant as any of those languages are 
regardless of how much better it may be.

- Jonathan M Davis
Sep 16 2011
next sibling parent reply "Nick Sabalausky" <a a.a> 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

 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."
Sep 17 2011
parent reply "Xavier" <xman nospam.net> writes:
"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).
Sep 17 2011
parent reply "Nick Sabalausky" <a a.a> 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?
Sep 17 2011
next sibling parent reply Josh Simmons <simmons.44 gmail.com> writes:
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.
Sep 17 2011
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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_.
Sep 17 2011
parent reply "Xavier" <xman nospam.net> writes:
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.
Sep 17 2011
parent Timon Gehr <timon.gehr gmx.ch> 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.
Sep 18 2011
prev sibling parent "Xavier" <xman nospam.net> 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.
Sep 17 2011
prev sibling next sibling parent reply J Arrizza <cppgent0 gmail.com> writes:
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

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.


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

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
Sep 17 2011
parent "Xavier" <xman nospam.net> writes:
J Arrizza wrote:

 Hmmm. If $100M was on the line, the project code base must be
 extremely large. Correct?


Hello. Next!
Sep 17 2011
prev sibling parent "Xavier" <xman nospam.net> 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?
Sep 17 2011
prev sibling next sibling parent reply "Xavier" <xman nospam.net> writes:
"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

 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?
Sep 17 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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

 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
Sep 17 2011
parent reply "Xavier" <xman nospam.net> writes:
"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

 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.
Sep 17 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Sep 17 2011
parent reply "Xavier" <xman nospam.net> writes:
"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". ;)
Sep 17 2011
parent Timon Gehr <timon.gehr gmx.ch> 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.
Sep 17 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> 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

 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, 

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.
Sep 17 2011
parent reply "Xavier" <xman nospam.net> writes:
"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

 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: 

 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.
Sep 17 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> 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

 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:

 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.
Sep 17 2011
prev sibling next sibling parent "Nick Sabalausky" <a a.a> 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: 

 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...
Sep 17 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 17 2011
parent renoX <renozyx gmail.com> 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
Sep 19 2011
prev sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> 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 

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.
Sep 17 2011
prev sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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.
Sep 17 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 17 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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/
Sep 17 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 17 2011
parent Peter Alexander <peter.alexander.au gmail.com> 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.
Sep 17 2011
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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
Sep 17 2011
parent Peter Alexander <peter.alexander.au gmail.com> 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.
Sep 17 2011
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Sep 17 2011
next sibling parent reply Josh Simmons <simmons.44 gmail.com> writes:
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.
Sep 17 2011
parent Adam D. Ruppe <destructionator gmail.com> 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.
Sep 17 2011
prev sibling next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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.
Sep 17 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Ah, that explains it. I usually don't use the -O switch.
Sep 17 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
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.
Sep 17 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
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.
Sep 17 2011
parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
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*
Sep 18 2011
parent Peter Alexander <peter.alexander.au gmail.com> 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.
Sep 18 2011
prev sibling parent reply Don <nospam nospam.com> writes:
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.
Sep 19 2011
next sibling parent Peter Alexander <peter.alexander.au gmail.com> 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?
Sep 19 2011
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> 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
Sep 19 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> 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
Sep 20 2011
prev sibling parent "Nick Sabalausky" <a a.a> 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.
Sep 17 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> 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.
Sep 17 2011
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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, converting libraries all take =
lots of time and money that have to be justified.

=20
 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.

It's absolutely about the toolchain.  I'd be curious to hear from anyone =
who has tried developing for the Xbox 360 using D, or any of the big 3 =
consoles, really.=
Sep 17 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 18/09/11 12:12 AM, Sean Kelly wrote:

 On Sep 17, 2011, at 8:08 AM, Peter Alexander wrote:

 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.


Unity builds help a lot with link time.



 I'd be curious to hear from anyone who has tried developing for the Xbox 360
using D, or any of the big 3 consoles, really.


Well, you'd need to target PowerPC for all current-gen consoles. Can GDC 
do that?
Sep 18 2011
next sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Peter Alexander wrote:

 On 18/09/11 12:12 AM, Sean Kelly wrote:

 On Sep 17, 2011, at 8:08 AM, Peter Alexander wrote:

 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.


=20
 Unity builds help a lot with link time.
=20


	Note that you can also use partial linking to help with link times
while iterating development on large projects. At least on Linux
(with the -r or -i options to ld), I do not know about optlink.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Sep 18 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/18/2011 3:27 AM, "Jérôme M. Berger" wrote:

 	Note that you can also use partial linking to help with link times
 while iterating development on large projects. At least on Linux
 (with the -r or -i options to ld), I do not know about optlink.


Optlink does not do incremental linking.
Sep 18 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/18/2011 2:49 AM, Peter Alexander wrote:

 Unity builds help a lot with link time.


dmd does something similar if you build an executable by putting multiple 
modules on the command line. It will create one big object file, instead of one 
per module.
Sep 18 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 18/09/11 7:59 PM, Walter Bright wrote:

 On 9/18/2011 2:49 AM, Peter Alexander wrote:

 Unity builds help a lot with link time.


 dmd does something similar if you build an executable by putting
 multiple modules on the command line. It will create one big object
 file, instead of one per module.


This is good.

Does dmd also cache commonly imported modules in this case?

e.g.

// foo.d
/+ lots of code +/

// bar.d
import foo;

// baz.d
import foo;

dmd foo.d bar.d baz.d

How many times is foo parsed? Once?
Sep 18 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/18/2011 3:33 PM, Peter Alexander wrote:

 Does dmd also cache commonly imported modules in this case?

 e.g.

 // foo.d
 /+ lots of code +/

 // bar.d
 import foo;

 // baz.d
 import foo;

 dmd foo.d bar.d baz.d

 How many times is foo parsed? Once?


Once.
Sep 18 2011
prev sibling parent "Xavier" <xman nospam.net> writes:
Peter Alexander wrote:


 This is false.
Sep 17 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article

 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.


This is exactly what I was thinking, and it's even more true now that D has two
fully open-source compilers.  GDC is almost usable on x86 already.  ("Almost"
here
means there's one showstopper bug that keeps me from using it for real work.) 
I'm
sure you could hire a dev or two to get it working well on ARM and/or PowerPC.
Think of all the money you'd save by not having to hire a bunch of extra people
to
write and maintain mountains of boilerplate.

If I were in charge of a company, the major place where I wouldn't use D would
be
in small but mission-critical projects.  If it's a big project, I could hire
someone to improve D tool support and probably make up the difference with
enhanced productivity.  If it's not that mission-critical then I don't need to
be
that risk-averse.
Sep 16 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 16/09/11 11:05 PM, dsimcha wrote:

 == Quote from Walter Bright (newshound2 digitalmars.com)'s article

 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.


 This is exactly what I was thinking, and it's even more true now that D has two
 fully open-source compilers.  GDC is almost usable on x86 already.  ("Almost"
here
 means there's one showstopper bug that keeps me from using it for real work.) 
I'm
 sure you could hire a dev or two to get it working well on ARM and/or PowerPC.
 Think of all the money you'd save by not having to hire a bunch of extra
people to
 write and maintain mountains of boilerplate.


Remember:

1. You don't get the money until the job is done.
2. It has to be done on time.

If you want to hire extra people then it comes out of your own money and 
you'll have to account for the time it would take to get all the tools 
working.
Sep 16 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/16/2011 3:34 PM, Peter Alexander wrote:

 Remember:

 1. You don't get the money until the job is done.


Sure, but you'd be getting an advance and progress payments. You can hire 
developers without paying them in advance, too.


 2. It has to be done on time.


D offers a lot of productivity improving abilities. That would offset time
spent 
improving the tools.
Sep 16 2011
prev sibling next sibling parent "Xavier" <xman nospam.net> writes:
Peter Alexander wrote:

 On 16/09/11 11:05 PM, dsimcha wrote:

 == Quote from Walter Bright (newshound2 digitalmars.com)'s article

 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.


 This is exactly what I was thinking, and it's even more true now
 that D has two fully open-source compilers.  GDC is almost usable on
 x86 already.  ("Almost" here means there's one showstopper bug that
 keeps me from using it for real work.)  I'm sure you could hire a
 dev or two to get it working well on ARM and/or PowerPC. Think of
 all the money you'd save by not having to hire a bunch of extra
 people to write and maintain mountains of boilerplate.


 Remember:

 1. You don't get the money until the job is done.


Don't be silly. Half before project start and the rest according to 
agreed upon payment schedule.


 2. It has to be done on time.


Project risk for the developer is high given the lack of scope definition 
and client wishful thinking, so this will only be offered as a Time and 
Materials project.


 If you want to hire extra people then it comes out of your own money


Nice try at "getting something for nothing" ClientFromHell, Inc.


 and you'll have to account for the time it would take to get all the
 tools working.


My my, someone is sure living in fantasyland. Time and Materials, take it 
or leave it.

Seriously, do people actually think that someone stupid enough to be 
sucked into shit like that are capable of developing something large and 
complex? (No they don't, they just want part of the work done to the 
point where they can sue the contractor and then move on to another 
victim without spending a dollar! Scumbags).
Sep 16 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-09-17 00:34, Peter Alexander wrote:

 This is exactly what I was thinking, and it's even more true now that
 D has two
 fully open-source compilers. GDC is almost usable on x86 already.
 ("Almost" here
 means there's one showstopper bug that keeps me from using it for real
 work.) I'm
 sure you could hire a dev or two to get it working well on ARM and/or
 PowerPC.
 Think of all the money you'd save by not having to hire a bunch of
 extra people to
 write and maintain mountains of boilerplate.


 Remember:

 1. You don't get the money until the job is done.



Is that really realistic for a large project like this. I assume it's a 
large project regarding the money involved. Wouldn't you divide the 
project in several smaller projects and get paid for the smaller projects?

-- 
/Jacob Carlborg
Sep 17 2011
prev sibling next sibling parent reply Jesse Phillips <jessekphillips+d gmail.com> writes:
On Fri, 16 Sep 2011 14:51:27 -0700, 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.


Problem is, he won't give me the money until it is done and delivered on 
time. Sadly I don't know a language to use to achieve that so D is my 
best choice. :D
Sep 16 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/16/2011 3:18 PM, Jesse Phillips wrote:

 Problem is, he won't give me the money until it is done and delivered on
 time.


If you're doing a $100,000,000 project that won't pay you a dime until it's 
delivered, you really need to renegotiate that contract :-)

Don't even do small projects that way. It's a great way to get stiffed. Even if 
you've got a slam-dunk case, it'll take you 3 years to get a judgment in court, 
and most of that will go to the lawyers. That's if they don't appeal, which can 
cost you another couple year delay. Then, you *still* aren't necessarily paid, 
you then have to go to court again to force payment.
Sep 16 2011
parent reply "Xavier" <xman nospam.net> writes:
Walter Bright wrote:

 On 9/16/2011 3:18 PM, Jesse Phillips wrote:

 Problem is, he won't give me the money until it is done and
 delivered on time.


 If you're doing a $100,000,000 project that won't pay you a dime
 until it's delivered, you really need to renegotiate that contract :-)

 Don't even do small projects that way. It's a great way to get
 stiffed.


It's amazing that this has to be said to anyone, at any age, at any time, 
at any place. I think the public schools are "teaching" "how to be a 
sheeple". What other reason could there be? It's a conspiracy, I tell ya.

Small project: half up front and all materials prepaid before 
procurement. Take it or leave it. Always be ready to walk away from a 
project. Trust your gut feelings. But I digress. Don't EVEN get me 
started on "work for hire"!
Sep 16 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Xavier" <xman nospam.net> wrote in message 
news:j50v3o$1gbb$1 digitalmars.com...

 I think the public schools are "teaching" "how to be a sheeple". What 
 other reason could there be?


Although I probably have about zero business sense, I absolutely agree on 
this part of what you said.

At one point, I went to Bowling Green State University, well known to be an 
"accept anyone and everyone even if we don't have enough room" party school. 
Most of the students there generally thought for themselves (even if most of 
them weren't particularly bright.)

Then I transfered to John Carroll University: a private school that, well, 
it's no Ivy-league, but it's fairly well-regarded, at least around the 
Cleveland area. Unlike BGSU, JCU is known to be fairly selective. But the 
vast majority of JCU students were complete mindless sheep. I'm being 
completely honest when I say it was actually somewhat disturbing how 
sheep-like they were. Of course, they were also just as dumb as the BGSU 
students, but unlike BGSU, most of them were uppity, conceited and had a 
noticeable tendency to mistake slogan and lecture regurgitation for 
intelligence, ability and independent thought.

Conclusion: High schools specifically cultivate sheeple, which is a quality 
preferred by "respectable" colleges.

I couldn't begin to speculate on why it's this way, or whether or not it's 
intentional by anyone who's still around. But whatever the reason, that's 
definitely how things are.
Sep 16 2011
next sibling parent reply "Xavier" <xman nospam.net> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:j51ef3$2a0d$1 digitalmars.com...

 "Xavier" <xman nospam.net> wrote in message 
 news:j50v3o$1gbb$1 digitalmars.com...

 I think the public schools are "teaching" "how to be a sheeple". What 
 other reason could there be?


 Although I probably have about zero business sense, I absolutely agree 
 on this part of what you said.

 At one point, I went to Bowling Green State University, well known to 
 be an "accept anyone and everyone even if we don't have enough room" 
 party school. Most of the students there generally thought for 
 themselves (even if most of them weren't particularly bright.)

 Then I transfered to John Carroll University: a private school that, 
 well, it's no Ivy-league, but it's fairly well-regarded, at least 
 around the Cleveland area. Unlike BGSU, JCU is known to be fairly 
 selective. But the vast majority of JCU students were complete mindless 
 sheep. I'm being completely honest when I say it was actually somewhat 
 disturbing how sheep-like they were. Of course, they were also just as 
 dumb as the BGSU students, but unlike BGSU, most of them were uppity, 
 conceited and had a noticeable tendency to mistake slogan and lecture 
 regurgitation for intelligence, ability and independent thought.

 Conclusion: High schools specifically cultivate sheeple, which is a 
 quality preferred by "respectable" colleges.

 I couldn't begin to speculate on why it's this way, or whether or not 
 it's intentional by anyone who's still around. But whatever the reason, 
 that's definitely how things are.


The most surprising thing to me is that it seems to work! It could be 
that most people simply are not very smart from the get go so they 
believe everything they read and are told and trust anyone and everyone. 
That's not it. (Well at first it may be, but surely at some point one 
becomes able to discern information of value from BS). It's not an 
intelligence thing. It's something else. I think I know what it is, but 
this is not the place to get into it. I do think that some of it shows 
thru a little in some of my posts. Then again, maybe the fat blonde bimbo 
is skinny now and I'm still stupid. Nah, that's not it. Certainly not.
Sep 17 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Xavier" <xman nospam.net> wrote in message 
news:j51kmt$2n7t$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:j51ef3$2a0d$1 digitalmars.com...

 "Xavier" <xman nospam.net> wrote in message 
 news:j50v3o$1gbb$1 digitalmars.com...

 I think the public schools are "teaching" "how to be a sheeple". What 
 other reason could there be?


 Although I probably have about zero business sense, I absolutely agree on 
 this part of what you said.

 At one point, I went to Bowling Green State University, well known to be 
 an "accept anyone and everyone even if we don't have enough room" party 
 school. Most of the students there generally thought for themselves (even 
 if most of them weren't particularly bright.)

 Then I transfered to John Carroll University: a private school that, 
 well, it's no Ivy-league, but it's fairly well-regarded, at least around 
 the Cleveland area. Unlike BGSU, JCU is known to be fairly selective. But 
 the vast majority of JCU students were complete mindless sheep. I'm being 
 completely honest when I say it was actually somewhat disturbing how 
 sheep-like they were. Of course, they were also just as dumb as the BGSU 
 students, but unlike BGSU, most of them were uppity, conceited and had a 
 noticeable tendency to mistake slogan and lecture regurgitation for 
 intelligence, ability and independent thought.

 Conclusion: High schools specifically cultivate sheeple, which is a 
 quality preferred by "respectable" colleges.

 I couldn't begin to speculate on why it's this way, or whether or not 
 it's intentional by anyone who's still around. But whatever the reason, 
 that's definitely how things are.


 The most surprising thing to me is that it seems to work! It could be that 
 most people simply are not very smart from the get go so they believe 
 everything they read and are told and trust anyone and everyone. That's 
 not it.


I almost wish it were. Then I could just say, "No, it's like this..." 
Problem solved. Or better yet, "Go make me a sandwich." Better problem 
solved :)


 (Well at first it may be, but surely at some point one becomes able to 
 discern information of value from BS). It's not an intelligence thing. 
 It's something else. I think I know what it is, but this is not the place 
 to get into it. I do think that some of it shows thru a little in some of 
 my posts. Then again, maybe the fat blonde bimbo is skinny now and I'm 
 still stupid. Nah, that's not it. Certainly not.
Sep 17 2011
parent reply David Nadlinger <see klickverbot.at> writes:
On 9/17/11 10:51 AM, Nick Sabalausky wrote:

 I almost wish it were. Then I could just say, "No, it's like this..."
 Problem solved. Or better yet, "Go make me a sandwich." Better problem
 solved :)


Have you tried using »sudo go make me a sandwich«? ;)

David
Sep 17 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"David Nadlinger" <see klickverbot.at> wrote in message 
news:j51nfi$2rjc$1 digitalmars.com...

 On 9/17/11 10:51 AM, Nick Sabalausky wrote:

 I almost wish it were. Then I could just say, "No, it's like this..."
 Problem solved. Or better yet, "Go make me a sandwich." Better problem
 solved :)


 Have you tried using »sudo go make me a sandwich«? ;)


XKCD FTW :)

Absolutely fantastic comic.

Since it's so late and I'm therefore so tired that I'm impulsive again, I'm 
going to list some other fantastic webcomics:

- Bunny
- Extra Life
- VG Cats
- Sexy Losers (NSFW, although I'm not sure it's even around anymore)
- Perry Bible Fellowship (not at all what it sounds like)
Sep 17 2011
prev sibling parent "Mike James" <foo bar.com> writes:
"David Nadlinger" <see klickverbot.at> wrote in message 
news:j51nfi$2rjc$1 digitalmars.com...

 On 9/17/11 10:51 AM, Nick Sabalausky wrote:

 I almost wish it were. Then I could just say, "No, it's like this..."
 Problem solved. Or better yet, "Go make me a sandwich." Better problem
 solved :)


 Have you tried using »sudo go make me a sandwich«? ;)

 David


Ah yes - the old favourite... :-)

http://xkcd.com/149/

-=mike=-
Sep 17 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 16, 2011, at 11:24 PM, Nick Sabalausky wrote:

=20
 Conclusion: High schools specifically cultivate sheeple, which is a =


quality=20

 preferred by "respectable" colleges.


Depends on the college and even on the professor, though it's obviously =
difficult for universities with large class sizes to accommodate any =
other form of teaching and grading than a basic regurgitation of facts.  =
Particularly in entry-level courses where the point of the course is to =
gain a basic knowledge of the field.=
Sep 17 2011
prev sibling parent "Xavier" <xman nospam.net> writes:
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.


Exactly. Like Google is doing with Go. No need for "general purpose" (or 
"novelty") when you have a "special purpose" budget.


 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.
Sep 16 2011
prev sibling next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
assuming I would ever be offered such a big project I would likely having to
work in a team. As there aren't that many other d programmers I've met it

I would bring d up though but it will only be taken seriously if
availability of other librarys aren't an issue. I wouldn't be afraid of the
more complex functions as long as it's self-explanatory assuming another
programmer is going to read it later and as there is a high chance he can't
program in D.

I do think dmd is a capable compiler as walter bright has a lot of
experience with writing compilers. Right now the eclipse plugin for d is
working very good and keeps getting better.
Sep 16 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+d gmail.com> writes:
On Fri, 16 Sep 2011 22:47:50 +0100, Peter Alexander wrote:


 I recently stumbled across this (old) blog post:
 http://prog21.dadgum.com/13.html
 
 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.

 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.


I agree with 1 and 5. If 1 isn't required then yes. For most everything 
else there is a work around. Libraries, you're no worse off than C, I'd 
much rather take the time to translate 100 headers or my own C wrapper 
than write the bulk of the program in C.

For such a project I'd probably develop more like C as D does still have 
issues with the newer features, but it is still 100x more pleasant.
Sep 16 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Peter Alexander" <peter.alexander.au gmail.com> wrote in message 
news:j50frj$m2k$1 digitalmars.com...

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?


As long as D *could* be used (ie, I had my choice of language, and there was 
no requirement of ARM, JVM, in-browser scripting/applet, or shared hosting 
without native-compiled custom CGI support, etc), then the more critical the 
project was, and the more money involved, the more I would *insist* on using 
D.
Sep 16 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 16/09/11 11:23 PM, Nick Sabalausky wrote:

 "Peter Alexander"<peter.alexander.au gmail.com>  wrote in message
 news:j50frj$m2k$1 digitalmars.com...

 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?


 As long as D *could* be used (ie, I had my choice of language, and there was
 no requirement of ARM, JVM, in-browser scripting/applet, or shared hosting
 without native-compiled custom CGI support, etc), then the more critical the
 project was, and the more money involved, the more I would *insist* on using
 D.


You don't know up front whether or not an ARM port will be required. The 
requirements are subject to change like any real project, although not 
excessively so (as he says in the post).
Sep 16 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/16/2011 3:37 PM, Peter Alexander wrote:

 You don't know up front whether or not an ARM port will be required. The
 requirements are subject to change like any real project, although not
 excessively so (as he says in the post).


If you had $100,000,000 to throw around, I can guarantee you an ARM port.

And for a heckuva lot less than that, too.
Sep 16 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Peter Alexander" <peter.alexander.au gmail.com> wrote in message 
news:j50io4$rdq$2 digitalmars.com...

 On 16/09/11 11:23 PM, Nick Sabalausky wrote:

 "Peter Alexander"<peter.alexander.au gmail.com>  wrote in message
 news:j50frj$m2k$1 digitalmars.com...

 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?


 As long as D *could* be used (ie, I had my choice of language, and there 
 was
 no requirement of ARM, JVM, in-browser scripting/applet, or shared 
 hosting
 without native-compiled custom CGI support, etc), then the more critical 
 the
 project was, and the more money involved, the more I would *insist* on 
 using
 D.


 You don't know up front whether or not an ARM port will be required. The 
 requirements are subject to change like any real project, although not 
 excessively so (as he says in the post).


If we assume requirements are subject to any unforseen changes, then *any* 
language would be prone to potential disaster. If we assume the "subject to 
changes" is not excessively so, then it's safe to consider a completely 
out-of-the-blue "oh, we need this an ARM" to be a comparatively low risk to 
other features that would have had at least some sort of early mention.

Plus, like Walter indicated, for that kind of money I could just hire 
someone, hell, even a whole company, to either do a langauge port or an ARM 
backend.
Sep 16 2011
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Sat, 17 Sep 2011 00:47:50 +0300, Peter Alexander  
<peter.alexander.au gmail.com> wrote:


 In summary, the author asks if you were offered $100,000,000 for some  
 big software project, would you use your pet programming language?


I think it's important to make the distinction between the language itself  
and its implementations.

Implementation problems take a constant amount of resources to fix. You  
could make D AAA-ready for a small part of that price.
However, the cost of using a clumsy programming language is directly  
proportional to the size of the project.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net
Sep 16 2011
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09/16/2011 11:47 PM, Peter Alexander wrote:

 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?


Yes, of course.


 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.


You have $1000000000 to spend. Hacking together ARM support or even just 
a C backend cannot be that hard.


 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.


Just split the giant codebase into modules and use di files. Linker 
tools are the same for D as C++ (except DMD Windows).


 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++.


DirectX is COM based, which means it can interface with D without a C 
layer. But there are also C API bindings.



 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.


Work around it, or develop a faster garbage collector. Again, 1000000000$.


 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.


Yah, DMDs error messages are cryptic sometimes. But 
const/immutable/shared are quite straightforward imho.


 ---

 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.


I have never needed more D specific tools than the D compiler itself.
Available libraries for D are a superset of available C libraries.
Sep 16 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
On 9/16/2011 7:51 PM, Timon Gehr wrote:

 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.


 Work around it, or develop a faster garbage collector. Again, 1000000000$.


BTW, the GC has massively improved in the past 7 months.  It's no Java 
Hotspot GC but I did make some optimizations that, depending on use 
case, make it between 25% and 1,000 **times** faster in DMD 2.053 and up 
than in previous releases.  Additionally, the 64-bit support (since 
2.052) reduces false pointer problems by making the address space more 
sparse and the NO_INTERIOR flag (added in 2.055) and its internal use 
with associative arrays further mitigates false pointer problems.
Sep 16 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09/17/2011 03:13 AM, dsimcha wrote:

 On 9/16/2011 7:51 PM, Timon Gehr wrote:

 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.


 Work around it, or develop a faster garbage collector. Again,
 1000000000$.


 BTW, the GC has massively improved in the past 7 months. It's no Java
 Hotspot GC but I did make some optimizations that, depending on use
 case, make it between 25% and 1,000 **times** faster in DMD 2.053 and up
 than in previous releases. Additionally, the 64-bit support (since
 2.052) reduces false pointer problems by making the address space more
 sparse and the NO_INTERIOR flag (added in 2.055) and its internal use
 with associative arrays further mitigates false pointer problems.


That is nice to hear, thanks! But as long as it is a simple mark and 
sweep GC, it will be very slow. I have written some nice 'GC benchmarks' 
while playing with the language, eg see:

http://pastebin.com/C6vf9DQQ

That program computes some hamming numbers in haskell-lazy-functional 
style. It takes around 20min with GC turned on, and iirc about 20s with 
GC turned off (on bearophiles machine, it runs out of memory on mine). 
All the GC allocations are from closures.
Sep 16 2011
prev sibling next sibling parent reply "Xavier" <xman nospam.net> writes:
Peter Alexander wrote:

 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,


While this is a "silly little hypothetical thread" (and it is Friday 
afterall so that probably explains the OP), I cannot fathom that amount 
being spent on just software on one project (though I've worked on one 
system, i.e., software + hardware, project worth 10's of millions). Maybe 
someone here can? Examples please, or give the largest one you can think 
of (it can be hypothetical). Remember, it's just software, not a system.
Sep 16 2011
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 16, 2011, at 7:09 PM, Xavier wrote:


 Peter Alexander wrote:

 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,


 
 While this is a "silly little hypothetical thread" (and it is Friday 
 afterall so that probably explains the OP), I cannot fathom that amount 
 being spent on just software on one project (though I've worked on one 
 system, i.e., software + hardware, project worth 10's of millions). Maybe 
 someone here can? Examples please, or give the largest one you can think 
 of (it can be hypothetical). Remember, it's just software, not a system. 


Top-tier computer game budgets are tens of millions of dollars.
Sep 16 2011
prev sibling next sibling parent reply Josh Simmons <simmons.44 gmail.com> writes:
On Sat, Sep 17, 2011 at 2:55 PM, Sean Kelly <sean invisibleduck.org> wrote:

 On Sep 16, 2011, at 7:09 PM, Xavier wrote:


 Peter Alexander wrote:

 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,


 While this is a "silly little hypothetical thread" (and it is Friday
 afterall so that probably explains the OP), I cannot fathom that amount
 being spent on just software on one project (though I've worked on one
 system, i.e., software + hardware, project worth 10's of millions). Maybe
 someone here can? Examples please, or give the largest one you can think
 of (it can be hypothetical). Remember, it's just software, not a system.


 Top-tier computer game budgets are tens of millions of dollars.


Writing a AAA game in D would mean fixing a whole bunch of D, way
easier to stick to what's proven.

You'd have to disable the collector or make it better than every
existing one, which in turn means you're not using most of the
standard library. This is OK though since AAA games generally don't
use standard library stuff anyway. You'd have to fix the codegen too
(or maybe develop further ldc or gdc) and build new tools for just
about everything.

So basically sure you could do anything with enough money, but why
would you do it the hard way?
Sep 16 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Josh Simmons" <simmons.44 gmail.com> wrote in message 
news:mailman.2920.1316237301.14074.digitalmars-d puremagic.com...

 On Sat, Sep 17, 2011 at 2:55 PM, Sean Kelly <sean invisibleduck.org> 
 wrote:

 On Sep 16, 2011, at 7:09 PM, Xavier wrote:


 Peter Alexander wrote:

 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,


 While this is a "silly little hypothetical thread" (and it is Friday
 afterall so that probably explains the OP), I cannot fathom that amount
 being spent on just software on one project (though I've worked on one
 system, i.e., software + hardware, project worth 10's of millions). 
 Maybe
 someone here can? Examples please, or give the largest one you can think
 of (it can be hypothetical). Remember, it's just software, not a system.


 Top-tier computer game budgets are tens of millions of dollars.


 Writing a AAA game in D would mean fixing a whole bunch of D, way
 easier to stick to what's proven.

 You'd have to disable the collector or make it better than every
 existing one, which in turn means you're not using most of the
 standard library. This is OK though since AAA games generally don't
 use standard library stuff anyway. You'd have to fix the codegen too
 (or maybe develop further ldc or gdc) and build new tools for just
 about everything.

 So basically sure you could do anything with enough money, but why
 would you do it the hard way?


Keep in mind, most of a AAA game's codebase is externally-developed 
middleware these days. I think the middleware development sector would be 
willing to fix those issues if it meant being able to provide a more 
competitive offering (ie, their customers can use an easier to use/learn 
language, and don't need as many C++ gurus, etc).

Of course, D will need more buzz in the game world to give middleware 
developers that push. But middleware provides a way around the question of 
"Why would game developers do it the hard way?" Their product may (arguably) 
end up the same either way for a game developer. But doing that hard stuff 
could make a middleware developer's product be more attractive ("It's kinda 


have, and you're not locked into MS platforms."). So there's the motivation 
for "the hard way".

Of course, personally, I'd consider using an already-working-but-C++-based 
toolchain to be "the hard way", but that's me.
Sep 17 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:j51ia4$2ivm$1 digitalmars.com...







 except you don't have that 5% performance hit, you have all this 

 not locked into MS platforms.").
Sep 17 2011
prev sibling parent reply Josh Simmons <simmons.44 gmail.com> writes:
On Sat, Sep 17, 2011 at 5:30 PM, Nick Sabalausky <a a.a> wrote:

 Keep in mind, most of a AAA game's codebase is externally-developed
 middleware these days. I think the middleware development sector would be
 willing to fix those issues if it meant being able to provide a more
 competitive offering (ie, their customers can use an easier to use/learn
 language, and don't need as many C++ gurus, etc).


You need high performance code gurus, the need for C++ people in
non-performance critical code is already alleviated by the scripting
world.

I disagree with your middleware statement too, most middleware at this
level is created by in house teams and then sold on for other titles.
For example CryEngine, Unreal Engine, id tech, source engine. Other
AAA engines are used entirely in-studio for example IW's engine(s) for
the CoD series games and Frostbite for the newer battlefield games.
The other problem with this idea is that the middleware needs to play
nice with other middleware like physics libraries, ai libraries and
other specialised bits of software like speedtree, which typically are
written in C++.

All of these layers need to be highly tuned for performance across
many platforms including the console world.


performance hit too, it makes the whole thing unfeasible. My feeling
is that the same is true of D due mostly to immature tooling.

The indie world however, is much more accommodating, the budgets are
lower and programmer productivity more important. Their performance
requirements are much lower and their willingness to play with new
tools is much greater. Make these guys happy and then down the track
the rest of the gaming world might follow.
Sep 17 2011
parent "Nick Sabalausky" <a a.a> writes:
"Josh Simmons" <simmons.44 gmail.com> wrote in message 
news:mailman.2922.1316246434.14074.digitalmars-d puremagic.com...

 On Sat, Sep 17, 2011 at 5:30 PM, Nick Sabalausky <a a.a> wrote:

 Keep in mind, most of a AAA game's codebase is externally-developed
 middleware these days. I think the middleware development sector would be
 willing to fix those issues if it meant being able to provide a more
 competitive offering (ie, their customers can use an easier to use/learn
 language, and don't need as many C++ gurus, etc).


 You need high performance code gurus, the need for C++ people in
 non-performance critical code is already alleviated by the scripting
 world.


Hmm, perhaps. Although I kinda have to agree with Carmack on game scripting 
not being such a great idea in the first place (Not that I feel that way 
because he said it). He also said said something in his last keynote that 
caught my attention, something about all that game scripting actually being 
more costly to performance than most people think. I don't know/remember the 
details, though. Although, coming from a guy who's idea of high-performace 
seems to have turned into "require a super-computer with expensive 
game-dedicated hardware" these days, I'm not sure how much I can still trust 
his stance on what code is/isn't fast anymore...But I guess I'm just being 
cynical...



 I disagree with your middleware statement too, most middleware at this
 level is created by in house teams and then sold on for other titles.
 For example CryEngine, Unreal Engine, id tech, source engine.


Renderware, Gamebryo, Unity, Vision Engine, and none-engine stuff like 
Havok, Although I admit I wouldn't know anything about maketshare.



 Other
 AAA engines are used entirely in-studio for example IW's engine(s) for
 the CoD series games and Frostbite for the newer battlefield games.
 The other problem with this idea is that the middleware needs to play
 nice with other middleware like physics libraries, ai libraries and
 other specialised bits of software like speedtree, which typically are
 written in C++.


Yea, I suppose engine would be the key one.



 All of these layers need to be highly tuned for performance across
 many platforms including the console world.


 performance hit too, it makes the whole thing unfeasible. My feeling
 is that the same is true of D due mostly to immature tooling.


With D it's not an intractable issue, though.



 The indie world however, is much more accommodating, the budgets are
 lower and programmer productivity more important. Their performance
 requirements are much lower and their willingness to play with new
 tools is much greater. Make these guys happy and then down the track
 the rest of the gaming world might follow.


Oh, absolutely. Totally agree. In fact that's where I am...Or...would 
be...if I wasn't stuck in this perpetual web-dev hell...
Sep 17 2011
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Josh Simmons wrote:

 So basically sure you could do anything with enough money, but why
 would you do it the hard way?


Because it will pay off in the longer term.

When I started writing web apps in D, it looked hard. I'd have to
get it compiling for the production server. Have to get my app
to interact with the web server somehow. Have to talk to the
database server. Have to read input from the browser.

That's just to get started. Then, it'd have to interact with
existing code, talk to external web services (http client and
oauth), maintain user sessions, and do html templating in some
kind of remotely sane way.

I might have to explain to clients and investors the advantages
too, and deal with whatever else comes up as time goes on - images,
desktop ports, and more ended up being needed too.


Sounds like a lot of effort when I could just write PHP or any
number of other existing things right now.


But, I knew that would pay for itself over time... and it was
actually even /better/ than I expected.

Writing those libraries went faster than I thought, partially
thanks to being able to use C libraries, and partially because
it wasn't really that hard anyway once I sat down and got started.

Compiling ended up being trivial - just a "make -f posix.mak"
on the server environment did the job making my dmd.

Justifying the choice was simple too: it's significantly more
productive, both to code and to write, than the alternatives,
and someone reasonably competent can learn it in a single day.


This up front investment has paid for itself a hundred times over.


Is my project representative of the OP's scenario? I don't know for
sure. But I'd be willing to place a big bet on yes.
Sep 17 2011
prev sibling next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 17/09/11 3:09 AM, Xavier wrote:

 Peter Alexander wrote:

 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,


 While this is a "silly little hypothetical thread" (and it is Friday
 afterall so that probably explains the OP), I cannot fathom that amount
 being spent on just software on one project (though I've worked on one
 system, i.e., software + hardware, project worth 10's of millions). Maybe
 someone here can? Examples please, or give the largest one you can think
 of (it can be hypothetical). Remember, it's just software, not a system.


The number is unimportant. It's just a placeholder. Could just be $100k 
if that makes it easier.

It's just a thought experiment: being honest, would you use D for a 
large project with high stakes?
Sep 17 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/17/11 9:53 AM, Peter Alexander wrote:

 On 17/09/11 3:09 AM, Xavier wrote:

 Peter Alexander wrote:

 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,


 While this is a "silly little hypothetical thread" (and it is Friday
 afterall so that probably explains the OP), I cannot fathom that amount
 being spent on just software on one project (though I've worked on one
 system, i.e., software + hardware, project worth 10's of millions). Maybe
 someone here can? Examples please, or give the largest one you can think
 of (it can be hypothetical). Remember, it's just software, not a system.


 The number is unimportant. It's just a placeholder. Could just be $100k
 if that makes it easier.

 It's just a thought experiment: being honest, would you use D for a
 large project with high stakes?


Well I did (which makes it less of a Gedankenexperiment). My doctorate 
is in machine learning applied to NLP, and a lot of research in this 
field consists of systems building. (It's quite surprising, really - 
once you have the data, the paper can be written the night before the 
submission.) The stakes were quite high to me personally - I had just 
switched fields (and statistically most who do give up later on), the 
field was new to me, I'd started a family, not to mention I was 
incurring opportunity losses in income. Being unable to complete my 
doctorate or spending much longer on it would have been quite a disaster.


Andrei
Sep 17 2011
next sibling parent "Xavier" <xman nospam.net> writes:
Andrei Alexandrescu wrote:


 My doctorate


And what about it?
Sep 17 2011
prev sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
attention: don't feed the troll
Sep 18 2011
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Sep 16, 2011, at 10:28 PM, Josh Simmons wrote:


 On Sat, Sep 17, 2011 at 2:55 PM, Sean Kelly <sean invisibleduck.org> =


wrote:

 On Sep 16, 2011, at 7:09 PM, Xavier wrote:
=20

 Peter Alexander wrote:

 I recently stumbled across this (old) blog post:
 http://prog21.dadgum.com/13.html
=20
 In summary, the author asks if you were offered $100,000,000 for =








some

 big software project,


=20
 While this is a "silly little hypothetical thread" (and it is Friday
 afterall so that probably explains the OP), I cannot fathom that =






amount

 being spent on just software on one project (though I've worked on =






one

 system, i.e., software + hardware, project worth 10's of millions). =






Maybe

 someone here can? Examples please, or give the largest one you can =






think

 of (it can be hypothetical). Remember, it's just software, not a =






system.

=20
 Top-tier computer game budgets are tens of millions of dollars.
=20


=20
 Writing a AAA game in D would mean fixing a whole bunch of D, way
 easier to stick to what's proven.
=20
 You'd have to disable the collector or make it better than every
 existing one, which in turn means you're not using most of the
 standard library. This is OK though since AAA games generally don't
 use standard library stuff anyway. You'd have to fix the codegen too
 (or maybe develop further ldc or gdc) and build new tools for just
 about everything.
=20
 So basically sure you could do anything with enough money, but why
 would you do it the hard way?


I didn't say I would.  That was merely an example of a multi-million =
dollar software project.=
Sep 17 2011
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
I already have!

Well, not $100 million unless I'm a lot luckier than I think I
am, but I use D every day for real world programs.
Sep 16 2011
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 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++.


That's a major problem.
With D you spend way too much time creating bindings or even wrappers to  
access external libraries rather than doing actual work.

We really need a proper tool to convert C/C++ headers, probably based on  
Clang.
That way one could even add partial conversion support for source files  
afterwards to ease porting.

And C++ interoperability needs to be improved.
It's just insane to wrap a monster like Qt in C code and then recreating  
the whole class hierarchy at the D site - both performance and executable  
file size wise.
Sep 18 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 9/18/2011 9:00 PM, Trass3r wrote:

 We really need a proper tool to convert C/C++ headers, probably based on
 Clang.
 That way one could even add partial conversion support for source files
 afterwards to ease porting.

 And C++ interoperability needs to be improved.
 It's just insane to wrap a monster like Qt in C code and then recreating
 the whole class hierarchy at the D site - both performance and
 executable file size wise.


I imagine C++ would be virtually impossible, but how hard can it 
possibly be to translate **non-preprocessor-abusing** C code to D?  D is 
almost a superset of C.  The only incompatibilities I can think of are 
the preprocessor/module system, bitfields, and some minor syntactic 
differences.  Am I missing anything important?
Sep 18 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/18/2011 6:06 PM, dsimcha wrote:

 I imagine C++ would be virtually impossible, but how hard can it possibly be to
 translate **non-preprocessor-abusing** C code to D? D is almost a superset of
C.
 The only incompatibilities I can think of are the preprocessor/module system,
 bitfields, and some minor syntactic differences. Am I missing anything
important?


http://www.digitalmars.com/d/2.0/htod.html
Sep 18 2011
next sibling parent reply Trass3r <un known.com> writes:
 http://www.digitalmars.com/d/2.0/htod.html


It's windows-only, discards const, doesn't turn static arrays into  
pointers IIRC and it depends on the dmc toolchain and system includes, so  
the library you want to use basically needs to be compatible with dmc.
All in all I'm much faster with a manual, maybe regex-supported conversion.
Sep 18 2011
parent Trass3r <un known.com> writes:
Oh, I think it also doesn't turn #ifdefs into version()s so you  
potentially lose another big chunk of information.
Sep 18 2011
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
On 9/18/2011 9:18 PM, Walter Bright wrote:

 On 9/18/2011 6:06 PM, dsimcha wrote:

 I imagine C++ would be virtually impossible, but how hard can it
 possibly be to
 translate **non-preprocessor-abusing** C code to D? D is almost a
 superset of C.
 The only incompatibilities I can think of are the preprocessor/module
 system,
 bitfields, and some minor syntactic differences. Am I missing anything
 important?


 http://www.digitalmars.com/d/2.0/htod.html



Right, but htod only translates headers.  I was talking about 
translating full **source code**.
Sep 18 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
Am 19.09.2011, 03:06 Uhr, schrieb dsimcha <dsimcha yahoo.com>:

 On 9/18/2011 9:00 PM, Trass3r wrote:

 And C++ interoperability needs to be improved.
 It's just insane to wrap a monster like Qt in C code and then recreating
 the whole class hierarchy at the D site - both performance and
 executable file size wise.


 I imagine C++ would be virtually impossible


Of course you can't support everything, but there sure is room for  
improvement:
http://d.puremagic.com/issues/show_bug.cgi?id=4620
Sep 18 2011
prev sibling parent Trass3r <un known.com> writes:
Am 19.09.2011, 03:06 Uhr, schrieb dsimcha <dsimcha yahoo.com>:

 how hard can it possibly be to translate **non-preprocessor-abusing** C  
 code to D?  D is almost a superset of C.  The only incompatibilities I  
 can think of are the preprocessor/module system, bitfields, and some  
 minor syntactic differences.  Am I missing anything important?


Yep, but C code does abuse the preprocessor.
Static arrays are another incompatibility, I'm not sure though if  
extern(C) automatically makes int[3] being passed by ref.
Sep 18 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-09-19 03:00, Trass3r wrote:

 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++.


 That's a major problem.
 With D you spend way too much time creating bindings or even wrappers to
 access external libraries rather than doing actual work.

 We really need a proper tool to convert C/C++ headers, probably based on
 Clang.


It's in the works: https://github.com/jacob-carlborg/clang
It's currently most focused on porting Objective-C headers. Don't count 
on it in the near future.

-- 
/Jacob Carlborg
Sep 19 2011
parent reply Trass3r <un known.com> writes:
Am 19.09.2011, 18:43 Uhr, schrieb Jacob Carlborg <doob me.com>:

 We really need a proper tool to convert C/C++ headers, probably based on
 Clang.


 It's in the works: https://github.com/jacob-carlborg/clang
 It's currently most focused on porting Objective-C headers. Don't count  
 on it in the near future.


I know, but didn't you say it's more of a patch/hack rather than using the  
rewrite facilities or whatever?
Sep 19 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-09-19 18:56, Trass3r wrote:

 Am 19.09.2011, 18:43 Uhr, schrieb Jacob Carlborg <doob me.com>:

 We really need a proper tool to convert C/C++ headers, probably based on
 Clang.


 It's in the works: https://github.com/jacob-carlborg/clang
 It's currently most focused on porting Objective-C headers. Don't
 count on it in the near future.


 I know, but didn't you say it's more of a patch/hack rather than using
 the rewrite facilities or whatever?


It does use the rewrite facilities. Maybe I said it was a hack how it's 
incorporated with clang. It's not built as a plugin and it doesn't use 
clang as a library. The repository contains the whole clang source code 
and I've added a new rewriter. It works just as the existing Objective-C 
rewriter that rewrite Objective-C to C or C++.

-- 
/Jacob Carlborg
Sep 19 2011
parent Trass3r <un known.com> writes:
 It does use the rewrite facilities. Maybe I said it was a hack how it's  
 incorporated with clang. It's not built as a plugin and it doesn't use  
 clang as a library. The repository contains the whole clang source code  
 and I've added a new rewriter. It works just as the existing Objective-C  
 rewriter that rewrite Objective-C to C or C++.


Ah ok. Sounds good then :)
Sep 19 2011
prev sibling next sibling parent mountain.li <mountain.li morningstar.com> writes:
Peter Alexander Wrote:
Yes


 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.
Sep 18 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
This thread is now on reddit:

http://www.reddit.com/r/programming/comments/kljc0/would_you_bet_100000000_on_d/
Sep 20 2011