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.

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.

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.

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

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?

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

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

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

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

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