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
next sibling 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 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 next 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 of the language. D is familiar enough for C++/C#/Java programmers to pick it up quickly. Especially for C++ programmers, given a sufficiently large timescale, it is not unthinkable that all time spent learning is recuperated by the productivity and scalability gains. I just cannot image a good C++ programmer having difficulty picking up D quickly.
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 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 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 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 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 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 "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 "Xavier" <xman nospam.net> writes:
Peter Alexander wrote:

 This is false.

Sep 17 2011
prev sibling 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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

Unity builds help a lot with link time. =20

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 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 languages such as C# and Java instead and are fine with that. D has a major uphill battle to truly become as relevant as any of those languages are regardless of how much better it may be. - Jonathan M Davis
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
 languages such as C# and Java instead and are fine with that. D has a 
 major
 uphill battle to truly become as relevant as any of those languages are
 regardless of how much better it may be.

I'm certainly aware of all that, and I do understand. But the question here wasn't "Do you think OTHER people feel language X is suitable for serious work?" It was "Do YOU think language X is suitable for serious work?" I don't doubt other people would disagree with me (especially people who haven't used D, and even probably some who have), but my own answer is "Yes, I think D is suitable for such projects, and in such a situation, yes, I would be willing to put my money where my mouth is."
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
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 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
 languages such as C# and Java instead and are fine with that. D has a 
 major
 uphill battle to truly become as relevant as any of those languages are
 regardless of how much better it may be.

There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills?
Sep 17 2011
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
 languages such as C# and Java instead and are fine with that. D has a 
 major
 uphill battle to truly become as relevant as any of those languages are
 regardless of how much better it may be.

There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills?

In both this and your other post, you're conflating the notions of the "language quality" vs "implementation quality". The two are not the same. Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating: For one thing, implementation quality is much easier to improve than language quality. An implementation deficiency can always be fixed. But a language deficiency can usually only be fixed if it's an additive change, which: #1 Rules out all non-additive improvements, and #2 Often forces an inferior solution to be used, creating language cruft. Secondly, it *IS* possible, and not at all uncommon, for a language deficiency to be MORE severe than an implementation deficiency. For example, updating header files and keeping them in-sync with the implementation is far more time consuming than working around any of the bugs in D's module system. Another: Certain details about C++ *force* the language to be slow-to-compile. That CANNOT be improved. As a consequence, many C++ projects take hours to compile. Unless you shell out the $$$ for a distributed-compilation cluster. Either way, that's much more costly than dealing with any D bug I've come across in the last year (yes, there were some severe ones in the past, but those are now fixed). So no, it's NOT a contradiction that D can be a better language while still having implementation issues.
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
 languages such as C# and Java instead and are fine with that. D has a 
 major
 uphill battle to truly become as relevant as any of those languages 
 are
 regardless of how much better it may be.

There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills?

In both this and your other post, you're conflating the notions of the "language quality" vs "implementation quality". The two are not the same.

They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language "quality" issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like "D is better than the POS that C++ is". To be markedly different from C++, D would have to be thought of as being in a different category than "which is the better POS?", but of course it cannot, for it comes from the same family, "one generation newer than C++".
 Now, yes, D effectively has one implementation (the DMD frontend), but 
 even considering that, the notions are still worth separating:

 For one thing, implementation quality is much easier to improve than 
 language quality.

That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas.
 An implementation deficiency can always be fixed. But a language 
 deficiency can usually only be fixed if it's an additive change, which: 
 #1 Rules out all non-additive improvements, and #2 Often forces an 
 inferior solution to be used, creating language cruft.

 Secondly, it *IS* possible, and not at all uncommon, for a language 
 deficiency to be MORE severe than an implementation deficiency. For 
 example, updating header files and keeping them in-sync with the 
 implementation is far more time consuming than working around any of 
 the bugs in D's module system. Another: Certain details about C++ 
 *force* the language to be slow-to-compile. That CANNOT be improved. As 
 a consequence, many C++ projects take hours to compile. Unless you 
 shell out the $$$ for a distributed-compilation cluster. Either way, 
 that's much more costly than dealing with any D bug I've come across in 
 the last year (yes, there were some severe ones in the past, but those 
 are now fixed).

So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that. And notice too that for software development that is not that, "intellisense" dramatically reduces the number of times a programmer hits the compile button. That one thing is not as big an issue and certainly it pales in comparison to other language design flaws, which C++ and D both share.
 So no, it's NOT a contradiction that D can be a better language while 
 still having implementation issues.

Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship.
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
 languages such as C# and Java instead and are fine with that. D has a
 major
 uphill battle to truly become as relevant as any of those languages
 are
 regardless of how much better it may be.

There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills?

In both this and your other post, you're conflating the notions of the "language quality" vs "implementation quality". The two are not the same.

They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language "quality" issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like "D is better than the POS that C++ is". To be markedly different from C++, D would have to be thought of as being in a different category than "which is the better POS?", but of course it cannot, for it comes from the same family, "one generation newer than C++".
 Now, yes, D effectively has one implementation (the DMD frontend), but
 even considering that, the notions are still worth separating:

 For one thing, implementation quality is much easier to improve than
 language quality.

That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas.
 An implementation deficiency can always be fixed. But a language
 deficiency can usually only be fixed if it's an additive change, which:
 #1 Rules out all non-additive improvements, and #2 Often forces an
 inferior solution to be used, creating language cruft.

 Secondly, it *IS* possible, and not at all uncommon, for a language
 deficiency to be MORE severe than an implementation deficiency. For
 example, updating header files and keeping them in-sync with the
 implementation is far more time consuming than working around any of
 the bugs in D's module system. Another: Certain details about C++
 *force* the language to be slow-to-compile. That CANNOT be improved. As
 a consequence, many C++ projects take hours to compile. Unless you
 shell out the $$$ for a distributed-compilation cluster. Either way,
 that's much more costly than dealing with any D bug I've come across in
 the last year (yes, there were some severe ones in the past, but those
 are now fixed).

So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that. And notice too that for software development that is not that, "intellisense" dramatically reduces the number of times a programmer hits the compile button.

I don't need intellisense, I'm fine with emacs. And compiling D code is usually so much faster than compiling C++ code that it is not even funny. Recompiling is not costly at all.
 That one thing is not as big an issue and certainly it pales in
 comparison to other language design flaws, which C++ and D both share.

Exactly which flaws are you talking about? Either get concrete so that your statements can be discussed and someone gets smarter in the process or stop making noise please.
 So no, it's NOT a contradiction that D can be a better language while
 still having implementation issues.

Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes).

Well, nobody wants to convince you that D and C++ don't belong to the same category. (as far language design goes). Whatever that means to you. But talking is worthless indeed. All your arguments are based on the wrong assumption that C++ and D are basically equal.
 You can call C++ a POS, but then, to me, that
 means that at best, D is just a better POS. But not to end this post on a
 bad note/word, I admire C++ a little bit. I certainly don't hate it.

Hating C++ is not a requirement for liking D better. Actually writing some lines of D code on the other hand, is.
 I can deal with it's shortcomings for now, so I could probably deal with
 D's also, but if I was thinking about jumping ship, I'd be swimming
 toward an island and not another ship.

If I want to reach an island, I usually don't swim. I take a ship that gets me there.
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: 
 #1 Rules out all non-additive improvements, and #2 Often forces an 
 inferior solution to be used, creating language cruft.

 Secondly, it *IS* possible, and not at all uncommon, for a language 
 deficiency to be MORE severe than an implementation deficiency. For 
 example, updating header files and keeping them in-sync with the 
 implementation is far more time consuming than working around any of the 
 bugs in D's module system. Another: Certain details about C++ *force* the 
 language to be slow-to-compile. That CANNOT be improved. As a 
 consequence, many C++ projects take hours to compile. Unless you shell 
 out the $$$ for a distributed-compilation cluster. Either way, that's 
 much more costly than dealing with any D bug I've come across in the last 
 year (yes, there were some severe ones in the past, but those are now 
 fixed).

So large scale software development is the only concern? Seems rather contrived point. C'mon now, a lot of software is NOT that.

You know perfectly well those were just examples.
 And notice too that for software development that is not that, 
 "intellisense" dramatically reduces the number of times a programmer hits 
 the compile button. That one thing is not as big an issue and certainly it 
 pales in comparison to other language design flaws, which C++ and D both 
 share.

1. IDE features are not substitutes for language improvement. 2. Such features don't end up in a IDE "for free". There's cost associated with actually putting them in there for a given language. You're not factoring that in. Additionally, this also implies that not everyone always has such features available.
 So no, it's NOT a contradiction that D can be a better language while 
 still having implementation issues.

Anyway, you can talk until you are blue in the face, but you can't convince me that D and C++ aren't in the same category (as far as language design goes). You can call C++ a POS, but then, to me, that means that at best, D is just a better POS. But not to end this post on a bad note/word, I admire C++ a little bit. I certainly don't hate it. I can deal with it's shortcomings for now, so I could probably deal with D's also, but if I was thinking about jumping ship, I'd be swimming toward an island and not another ship.

Yes, because if one boat starts sinking, they're all about to start sinking... And if you felt sick due to kidney failure, you'd insist that replacing the kidney will just make you slightly less sick. So you'd insist the doctor also replace your heart, your hip and your leg, fuse your spine, perform brain surgery, die your hair, and give you glasses, dentures and a facelift...
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

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 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
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 parent reply J Arrizza <cppgent0 gmail.com> writes:
--bcaec51f97e91ce4d304ad20b755
Content-Type: text/plain; charset=ISO-8859-1

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

With a code base of that size, more than half would be common or boilerplate
functionality, e.g. read a config file, read a data file, write/update a
file, parse the command line, maintain a list, put up a window, etc. All
been done before, all mundane, all "boring".

There would be 20-30% of truly new code specific to the project. Not really
boring code, not really exciting code. Probably wouldn't require any
specific language features. I would worry about large-scale project support
from the language, e.g. package/module isolation, minimal compilation time,
debug support, etc. IDE availability and tool support in general would be
factors too.

And finally there would be 5-10%, perhaps less, of the code base which was
"exciting". It would require certain language features or capabilities that
only a language like D could provide.

Given that project layout, what I would want then is a language *and*
development kit that had the full project requirements covered. If the
"exciting" stuff could be covered by Java or C#, I'd use Java/C# since the
vast majority of the "boring" functionality would be already available to me
in the JDK/CLR. If the "exciting" stuff, could only be covered by D, then
I'd worry how I was going to write all that "boring" code in time,
especially if I had to guarantee some level of defect rate.

The JDK/CLR rides on top of Java/C#, both OK languages with OK features.
Having the JDK/CLR available and tested by millions of developers? Very,
very appealing. I could of course redevelop or convert, for example, a DOM
XML parser in D, but that takes time. Would I want to spend the development
time and debug time in this project to hit a low defect rate on boring code?
Or would I just go with a language & development kit that already had a wide
code base and known defect rate. Generally speaking I believe low defect
rates are due to time passing - get a large number of people kicking at a
bunch of code over a long period of time, eventually the bugs get fixed. The
concern is will there be enough time in the project for that effect to
naturally run its course?

So D right now has Phobos and Tango. Both are good, but not fully featured
and, relatively speaking, untried. I could plan for a roll-yer-own
development kit from scratch. Daunting. I could plan to patch together a
whole set of converted C/C++ libraries. I could start with a conversion of
Boost or something similar to D and add to it as I needed. But all this
pales when compared to the 5,000/3,000 classes already written for me
in JDK/CLR. That's a heck of a lot of code, all with a relatively low (and
at least known) defect rate that I don't have to write. The less code I
write, the more of that $100M stays in my pocket, right?

In short, it's not D itself that would drive my decision to use or not use
D. It is the extent and quality of the development kit that goes along with
it. Of course, if the "exciting" part of the project was a solid fit with D
then my decision would naturally swing that way. But if a language like
Java/C# could do that part for me, I'd go with it and its JDK/CLR in a
heartbeat.

As a side note: the interesting twist here to me is that D language features
themselves promote the possibility of a very high quality DeeDK. It would
certainly be faster, and with enough unit testing and diligence, of a better
quality than JDK/CLR could ever hope to be.

John

--bcaec51f97e91ce4d304ad20b755
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hmmm. If $100M was on the line, the project code base must be extremely lar=
ge. Correct?=A0<div><br></div><div>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 &quot;b=
oring&quot;.</div>
<div><br></div><div>There would be 20-30% of truly new code specific to the=
 project. Not really boring code, not really exciting code. Probably wouldn=
&#39;t require any specific language features. I would worry about large-sc=
ale project support from the language, e.g. package/module isolation, minim=
al compilation time, debug support, etc. IDE=A0availability=A0and tool supp=
ort in general would be factors too.</div>
<div><br></div><div>And finally there would be 5-10%, perhaps less, of the =
code base which was &quot;exciting&quot;. It would require certain language=
 features or capabilities that only a language like D could provide.</div>
<div><br></div><div>Given that project layout, what I would want then is a =
language *and* development kit that had the full project requirements cover=
ed. If the &quot;exciting&quot; stuff could be covered by Java or C#, I&#39=
;d use Java/C# since the vast majority of the &quot;boring&quot; functional=
ity would be already available to me in the JDK/CLR. If the &quot;exciting&=
quot; stuff, could only be covered by D, then I&#39;d worry how I was going=
 to write all that &quot;boring&quot; code in time, especially if I had to=
=A0guarantee=A0some level of defect rate.</div>
<div><br></div><div>The JDK/CLR rides on top of Java/C#, both OK languages =
with OK features. Having the JDK/CLR available and tested by millions of de=
velopers? 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 ra=
te on boring code? Or would I just go with a language &amp; development kit=
 that already had a wide code base and known defect rate. Generally speakin=
g=A0I 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, eventuall=
y the bugs get fixed. The concern is will there be enough time in the proje=
ct for that effect to naturally run its course?</div>
<div><br></div><div>So D right now has Phobos and Tango. Both are good, but=
 not fully featured and, relatively speaking, untried. I could plan for a r=
oll-yer-own development kit from scratch. Daunting.=A0I could plan to patch=
 together a whole set of converted C/C++ libraries. I could start with a co=
nversion of Boost=A0or something similar to D and add to it as I needed. Bu=
t all this pales when compared to the=A05,000/3,000 classes already written=
 for me in=A0JDK/CLR. That&#39;s a heck of a lot of code, all with a relati=
vely low (and at least known) defect rate that I don&#39;t have to write. T=
he less code I write, the more of that $100M stays in my pocket, right?</di=
v>
<div><br></div><div>In short, it&#39;s not D itself that would drive my dec=
ision 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 &quot;exciting&quot; part of=
 the project was a solid fit with D then my decision would naturally swing =
that way. But if a language like Java/C# could do that part for me, I&#39;d=
 go with it and its JDK/CLR in a heartbeat.</div>
<div><br></div><div>As a side note: the interesting twist here to me is tha=
t D language features themselves promote the possibility of a very high qua=
lity 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.</div>
<div><br></div><div>John</div><div><br></div>

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

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.

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.

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
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 next 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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 =

 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 next sibling parent 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 =


 of AAA C++ games are known to take upwards of a full day (not sure =


 that's using a compile farm, but even if it is, D could still cut =


 compile farm expenses, or possibly even the need for one).

This is false. You can easily build several million lines of code in =

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 =

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 =


 why AAA game dev is C++ instead of D is ultimately because of =


 the languages themselves, or even the tools (If the AAA game dev =


 genuinely wanted to be using D, you can bet that any tools they =


 get made).

Tools are not free. Don't assume just because a company is large that =

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 =

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
prev sibling next sibling parent "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
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 next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
--0016e6d9772adadbc104ad161ef3
Content-Type: text/plain; charset=ISO-8859-1

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
would likely be in jave or c# (maybe c++).
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.

--0016e6d9772adadbc104ad161ef3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

assuming I would ever be offered such a big project I would likely having t=
o work in a team. As there aren&#39;t that many other d programmers I&#39;v=
e met it would likely be in jave or c# (maybe c++).<br>I would bring d up t=
hough but it will only be taken seriously if availability of other librarys=
 aren&#39;t an issue. I wouldn&#39;t be afraid of the more complex function=
s as long as it&#39;s self-explanatory assuming another programmer is going=
 to read it later and as there is a high chance he can&#39;t program in D.<=
br>
<br>I do think dmd is a capable compiler as walter bright has a lot of expe=
rience with writing compilers. Right now the eclipse plugin for d is workin=
g very good and keeps getting better.<br>=A0

--0016e6d9772adadbc104ad161ef3--
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 like moving from C++ to C#, except you don't have that 5% performance hit, you have all this metaprogramming and concurrency stuff C++ and C# don't 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
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:j51ia4$2ivm$1 digitalmars.com...
 ("It's kinda like moving from C++ to C#,

That is, "C# and/or XNA".
 except you don't have that 5% performance hit, you have all this 
 metaprogramming and concurrency stuff C++ and C# don't have, and you're 
 not locked into MS platforms.").
 

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 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. At this level the switch to C# provides much more than a 5% 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.

 At this level the switch to C# provides much more than a 5%
 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 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
parent "Xavier" <xman nospam.net> writes:
Andrei Alexandrescu wrote:

 My doctorate

And what about it?
Sep 17 2011
prev sibling next 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> =

 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 =




 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 =



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



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



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



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



=20
 Top-tier computer game budgets are tens of millions of dollars.
=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 parent maarten van damme <maartenvd1994 gmail.com> writes:
--0016e6d7eb467534d404ad35ddb2
Content-Type: text/plain; charset=ISO-8859-1

attention: don't feed the troll

--0016e6d7eb467534d404ad35ddb2
Content-Type: text/html; charset=ISO-8859-1

attention: don&#39;t feed the troll<br>

--0016e6d7eb467534d404ad35ddb2--
Sep 18 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 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
 languages such as C# and Java instead and are fine with that. D has a
 major
 uphill battle to truly become as relevant as any of those languages are
 regardless of how much better it may be.

There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills?

The language itself is superior. It's the implementation which has issues, though those have been being resolved at a fairly fast pace of late. - Jonathan M Davis
Sep 17 2011
parent "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
 languages such as C# and Java instead and are fine with that. D has 
 a
 major
 uphill battle to truly become as relevant as any of those languages 
 are
 regardless of how much better it may be.

There is something wrong with that last sentence. Especially since in the preceding material that I snipped, you noted that the compilers for D are not up to snuff. You seem to be noting its deficiencies but wanting it to be "better" somehow, maybe for some of it's "neat features"? Perhaps D just has to grow up before it can battle anywhere, let alone on hills?

The language itself is superior.

A family of languages goes from "crappy" to "superior" in one generation? Umm, I don't think so, "fan boy". ;)
 It's the implementation which has issues,
 though those have been being resolved at a fairly fast pace of late.

It's not just that, though I believe that you think that.
Sep 17 2011
prev sibling next sibling 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 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
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
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 next sibling parent 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
prev sibling next sibling 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 next 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 next 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 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
prev sibling next sibling parent 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
prev sibling 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