Re: Would You Bet $100,000,000 on D?
On Mon, 19 Sep 2011 18:27:29 -0400, Don nos...@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
Re: Would You Bet $100,000,000 on D?
This thread is now on reddit: http://www.reddit.com/r/programming/comments/kljc0/would_you_bet_1_on_d/
Re: Would You Bet $100,000,000 on D?
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 Sabalauskya@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.
Re: Would You Bet $100,000,000 on D?
On 18/09/11 8:59 AM, Marco Leise wrote: Am 17.09.2011, 22:33 Uhr, schrieb Peter Alexander peter.alexander...@gmail.com: On 17/09/11 7:52 PM, Marco Leise wrote: Am 17.09.2011, 20:01 Uhr, schrieb Adam D. Ruppe destructiona...@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.
Re: Would You Bet $100,000,000 on D?
attention: don't feed the troll
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
Timon Gehr wrote: 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 Sabalauskya@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. Why don't you consider doing that?
Re: Would You Bet $100,000,000 on D?
maarten van damme wrote: attention: don't feed the troll attemtion: don't vote for the politician, or simply don't vote.
Re: Would You Bet $100,000,000 on D?
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?
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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?
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
Am 19.09.2011, 03:06 Uhr, schrieb dsimcha dsim...@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
Re: Would You Bet $100,000,000 on D?
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**.
Re: Would You Bet $100,000,000 on D?
Am 19.09.2011, 03:06 Uhr, schrieb dsimcha dsim...@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.
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
Oh, I think it also doesn't turn #ifdefs into version()s so you potentially lose another big chunk of information.
Re: Would You Bet $100,000,000 on D?
Python is a great Python but an awful C++, not to mention the converse. D, on the other hand, is arguably a much better C++ and also a pretty good Python. Pretty good as in pretty bad for integer operations where Python3 use big int and D silently corrupt your data in case of overflow like C/C++ if memory serves. BR, renoX
Re: Would You Bet $100,000,000 on D?
Am 19.09.2011, 18:43 Uhr, schrieb Jacob Carlborg d...@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?
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
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 :)
Re: Would You Bet $100,000,000 on D?
On 2011-09-19 18:56, Trass3r wrote: Am 19.09.2011, 18:43 Uhr, schrieb Jacob Carlborg d...@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
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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?
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
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
[OT] Schools and sheeple (was: Would You Bet $100,000,000 on D?)
Xavier x...@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.
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.2921.1316239886.14074.digitalmar...@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.
Re: Would You Bet $100,000,000 on D?
Josh Simmons simmons...@gmail.com wrote in message news:mailman.2920.1316237301.14074.digitalmar...@puremagic.com... On Sat, Sep 17, 2011 at 2:55 PM, Sean Kelly s...@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.
Re: Would You Bet $100,000,000 on D?
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.).
Re: Would You Bet $100,000,000 on D?
Nick Sabalausky a@a.a wrote in message
news:j51h52$2h0e$1...@digitalmars.com...
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.2921.1316239886.14074.digitalmar...@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).
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@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?
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
On Saturday, September 17, 2011 02:26:12 Xavier wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@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
Re: [OT] Schools and sheeple (was: Would You Bet $100,000,000 on D?)
Nick Sabalausky a@a.a wrote in message news:j51ef3$2a0d$1...@digitalmars.com... Xavier x...@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.
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2923.1316247041.14074.digitalmar...@puremagic.com... On Saturday, September 17, 2011 02:26:12 Xavier wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@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.
Re: Would You Bet $100,000,000 on D?
On Saturday, September 17, 2011 03:17:27 Xavier wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2923.1316247041.14074.digitalmar...@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
Re: Would You Bet $100,000,000 on D?
Xavier x...@nospam.net wrote in message news:j51jsp$2lln$1...@digitalmars.com... Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@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.
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2924.1316247900.14074.digitalmar...@puremagic.com... On Saturday, September 17, 2011 03:17:27 Xavier wrote: Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2923.1316247041.14074.digitalmar...@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. ;)
Re: Would You Bet $100,000,000 on D?
Xavier x...@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 jmdavisp...@gmx.com wrote in message
news:mailman.2921.1316239886.14074.digitalmar...@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
Re: [OT] Schools and sheeple (was: Would You Bet $100,000,000 on D?)
Xavier x...@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 x...@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.
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
On 09/17/2011 10:40 AM, Xavier wrote: Jonathan M Davisjmdavisp...@gmx.com wrote in message news:mailman.2924.1316247900.14074.digitalmar...@puremagic.com... On Saturday, September 17, 2011 03:17:27 Xavier wrote: Jonathan M Davisjmdavisp...@gmx.com wrote in message news:mailman.2923.1316247041.14074.digitalmar...@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.
Re: Would You Bet $100,000,000 on D?
Nick Sabalausky a@a.a wrote in message news:j51m0l$2prg$1...@digitalmars.com... Xavier x...@nospam.net wrote in message news:j51jsp$2lln$1...@digitalmars.com... Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@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.
Re: Would You Bet $100,000,000 on D?
On 09/17/2011 10:57 AM, Josh Simmons wrote: On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalauskya@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_.
Re: Would You Bet $100,000,000 on D?
Josh Simmons simmons...@gmail.com wrote in message news:mailman.2922.1316246434.14074.digitalmar...@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...
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
On 09/17/2011 11:17 AM, Xavier wrote: Nick Sabalauskya@a.a wrote in message news:j51m0l$2prg$1...@digitalmars.com... Xavierx...@nospam.net wrote in message news:j51jsp$2lln$1...@digitalmars.com... Jonathan M Davisjmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@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++
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
Xavier x...@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
Re: Would You Bet $100,000,000 on D?
On Sat, Sep 17, 2011 at 7:34 PM, Nick Sabalausky a@a.a wrote: Renderware, Gamebryo, Unity, Vision Engine, and none-engine stuff like Havok, Although I admit I wouldn't know anything about maketshare. Well RenderWare doesn't exist anymore, Bing Gordon, an EA executive, has stated that RenderWare didn't perform well enough for next-gen[clarification needed] and that RenderWare didn't stand up to competition from Epic Games. He has also stated that the RenderWare team is mostly a dev house (indicating that EA is reluctant to still use RenderWare)., Gamebryo at last I heard was no longer developed since the parent company went bust, Unity is really an indie outfit, and I don't know much about Vision Engine. There's also no way you could write Havok in D since nobody would purchase middleware they couldn't use in their existing codebases. (with their existing tools, too) If you wanted to break into Unity's market (good luck with that) though, D might be a reasonable choice. Although the language flexibility of Mono seems to be working in their favor.
Re: Would You Bet $100,000,000 on D?
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?
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
On 17/09/11 6:53 AM, Nick Sabalausky wrote: Peter Alexanderpeter.alexander...@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.
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
On Sun, Sep 18, 2011 at 1:32 AM, Adam D. Ruppe destructiona...@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.
Re: Would You Bet $100,000,000 on D?
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
500 7001004 83684906 total
$ time dmd *.d
Segmentation fault
real0m29.915s
user0m26.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
real0m45.363s
user0m26.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 00400f20
real0m10.439s
user0m9.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
real1m44.632s
user1m17.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.
Re: Would You Bet $100,000,000 on D?
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/
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
Ah, that explains it. I usually don't use the -O switch.
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
Am 17.09.2011, 20:01 Uhr, schrieb Adam D. Ruppe destructiona...@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.
Re: Would You Bet $100,000,000 on D?
Adam D. Ruppe destructiona...@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.
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
On Sat, 17 Sep 2011 20:55:38 +0300, Peter Alexander peter.alexander...@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, Vladimirmailto:vladi...@thecybershadow.net
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
On 17/09/11 8:59 PM, Vladimir Panteleev wrote: On Sat, 17 Sep 2011 20:55:38 +0300, Peter Alexander peter.alexander...@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.
Re: Would You Bet $100,000,000 on D?
On 17/09/11 7:52 PM, Marco Leise wrote: Am 17.09.2011, 20:01 Uhr, schrieb Adam D. Ruppe destructiona...@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.
Re: [OT] Schools and sheeple (was: Would You Bet $100,000,000 on D?)
On Sep 16, 2011, at 11:24 PM, Nick Sabalausky wrote: Conclusion: High schools specifically cultivate sheeple, which is a quality 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.
Re: Would You Bet $100,000,000 on D?
On Sep 17, 2011, at 8: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. Linking can still be pretty time consuming. My last big project was several million LOC broken into a tree of projects that all eventually produced a handful of large applications. This was a originally SPARC Solaris app so we couldn't spread the build across PCs, but rather built in parallel on big fancy machines. When I started, a full build took the better part of a work day, and before I left a full build was perhaps 30 minutes (my memory is a bit fuzzy here, but that sounds like a reasonable ballpark). The average level of parallelism was 10-20 cores working on the build using make -j. I suppose it's worth mentioning that building on Opteron was significantly faster, even using fewer cores. The code used almost no templates, which is a significant factor in total compile time. In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. I am unaware of any distributed, incremental build systems for D, so I see no particular speed advantage to using D (certainly not orders of magnitude anyway). My current project builds in 15 minutes on its current, ancient build machine at work. Written in C. A full build on my PC is under 5 minutes. Obviously, compile time isn't the only reason to choose D over some other language though. I'm sure there are smaller reasons too, but I'm convinced the primary reason why AAA game dev is C++ instead of D is ultimately because of inertia, not the languages themselves, or even the tools (If the AAA game dev industry genuinely wanted to be using D, you can bet that any tools they needed would get made). 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. 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.
Re: Would You Bet $100,000,000 on D?
On Sep 16, 2011, at 10:28 PM, Josh Simmons wrote: On Sat, Sep 17, 2011 at 2:55 PM, Sean Kelly s...@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? I didn't say I would. That was merely an example of a multi-million dollar software project.
Re: Would You Bet $100,000,000 on D?
Nick Sabalausky a@a.a wrote in message news:j51mq9$2r1t$1...@digitalmars.com... Xavier x...@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 jmdavisp...@gmx.com wrote in message news:mailman.2921.1316239886.14074.digitalmar...@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
Re: Would You Bet $100,000,000 on D?
Timon Gehr wrote: On 09/17/2011 10:57 AM, Josh Simmons wrote: On Sat, Sep 17, 2011 at 6:46 PM, Nick Sabalauskya@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.
Re: Would You Bet $100,000,000 on D?
Jacob Carlborg wrote: 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. It is if you are stupid enough to actually bite on that Craigslist-type ad! I assume it's a large project Well aren't you the brightest knob on the door! regarding the money involved. Ah, so THAT is what tipped you off, huh. Wouldn't you divide the project in several smaller projects and get paid for the smaller projects? You're not as dumb as I look! (Good for you, but I don't think we even want the project).
Re: Would You Bet $100,000,000 on D?
J Arrizza wrote: Hmmm. If $100M was on the line, the project code base must be extremely large. Correct? Hello. Next!
Re: Would You Bet $100,000,000 on D?
Josh Simmons simmons...@gmail.com wrote in message news:mailman.2925.1316249875.14074.digitalmar...@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.
Re: Would You Bet $100,000,000 on D?
Nick Sabalausky wrote: Xavier x...@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 Uh, uh... do NOT tell me what I am ultimately saying, K? K. (Your stupid use of the language, noted :P). 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. You are so confused, you don't even know which way is up, let alone forward. In my experience (not to quote James Kanze, though :P), I learned (was whipped by that soundbox one too many times... or YOU CAN'T HANDLE THE TRUTH!) to pluck those strings differently, and a stupid lil box with steel strings, became my... someone.. oh fuck you already and get the fuck out of my face. Compile that with your semicolon synchronization crutch. That aside (read, ignore it), why take you take you AMP, and shove it. Whatch ya gonna do without electricity, fan boy, huh? Replacing the two crappy strings won't be enough to make it sound significantly better. You are way out of your league. What you're missing Don't you tell me what I'm missing. is that a minority portion *can* ruin a whole. Take your politics elsewhere, I am not your audience. 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. Like I say, I reject your drugs. Push on me, I may get mad. Push on someone else, I may get furious. Your notion that a big imporvement requires a big change is just plain false. And maybe if you try to put words in my mouth one more time, you will taste aligator skin? 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. Contraire!! You were politicing, bitch. Dish it out... take it. Changing your story now? 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. Numbering stuff does not make it significant. I don't
Re: Would You Bet $100,000,000 on D?
Andrei Alexandrescu wrote: 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 Nuh uh.. don't you even start that (or do it, but leave me out of it). 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). Dude, I think you your fundamental sword, carefully. For instance, I am not likely to entertain, that kind of crap. I'd go on with the absurdity, and maybe want to (don't count on it, audience), but I don't want to maybe. A coworker of mine, for example, doesn't mind a speed penalty of 2-5x, OK, you are trying to fish me. Why?? 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, I'm not sorry for missing your interjecting point, at al, FYI. And don't tell me what my metaphor is/was, because you will only annoy me more. swimming from a ship to an island would entail It was my thought, so get the fuck out of it. OK? [snippage} I painted on the wall and you want to know what it means? (Don't dare me Andrei, to TELL YOU THE TRUTH!). :P
Re: Would You Bet $100,000,000 on D?
Lutger Blijdestijn wrote: 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. I got your job right here, rapist.
Re: Would You Bet $100,000,000 on D?
Peter Alexander wrote: This is false.
Re: Would You Bet $100,000,000 on D?
On Saturday, September 17, 2011 23:32:20 Xavier wrote: I got your job right here, rapist. If you're not going to be civil, then please stop posting. It's one thing to discuss something. It's something else entirely to be rude about it. It's completely unproductive and just wastes everyone's time. - Jonathan M Davis
Re: Would You Bet $100,000,000 on D?
Jonathan M Davis wrote: On Saturday, September 17, 2011 23:32:20 Xavier wrote: I got your job right here, rapist. If you're not going to be civil, then please stop posting. I dare you to make me vote. Bring it, asshat. I dare you. It's one thing to discuss something. It's something else entirely to be rude about it. It's completely unproductive and just wastes everyone's time. It's quite another to ween away from mommies tit.
Re: Would You Bet $100,000,000 on D?
Andrei Alexandrescu wrote: My doctorate And what about it?
Re: Would You Bet $100,000,000 on D?
Andrei Alexandrescu wrote: My doctorate I dare you to cry me a fucking river with your doctorat give it up man, rape is wrong. no need for war.
Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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?
Re: Would You Bet $100,000,000 on D?
== Quote from Walter Bright (newshou...@digitalmars.com)'s article On 9/16/2011 2:47 PM, Peter Alexander wrote: Essentially, I agree with his conclusion in the post. Tools and libraries would be my biggest concerns (in that order). The fact that D (usually) makes things easier for me barely registered when thinking about this. If you had $100,000,000 none of these are an issue, as you can easily afford to hire top developers to address any and all of them. There's a reason why huge companies like Microsoft, Google, Intel and Apple bring compiler dev in house. It's because they are so heavily reliant on compiler technology, they cannot afford not to. This is exactly what I was thinking, and it's even more true now that D has two fully open-source compilers. GDC is almost usable on x86 already. (Almost here means there's one showstopper bug that keeps me from using it for real work.) I'm sure you could hire a dev or two to get it working well on ARM and/or PowerPC. Think of all the money you'd save by not having to hire a bunch of extra people to write and maintain mountains of boilerplate. If I were in charge of a company, the major place where I wouldn't use D would be in small but mission-critical projects. If it's a big project, I could hire someone to improve D tool support and probably make up the difference with enhanced productivity. If it's not that mission-critical then I don't need to be that risk-averse.
Re: Would You Bet $100,000,000 on D?
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.
Re: Would You Bet $100,000,000 on D?
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
Re: Would You Bet $100,000,000 on D?
Peter Alexander peter.alexander...@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.
Re: Would You Bet $100,000,000 on D?
On 16/09/11 11:05 PM, dsimcha wrote: == Quote from Walter Bright (newshou...@digitalmars.com)'s article On 9/16/2011 2:47 PM, Peter Alexander wrote: Essentially, I agree with his conclusion in the post. Tools and libraries would be my biggest concerns (in that order). The fact that D (usually) makes things easier for me barely registered when thinking about this. If you had $100,000,000 none of these are an issue, as you can easily afford to hire top developers to address any and all of them. There's a reason why huge companies like Microsoft, Google, Intel and Apple bring compiler dev in house. It's because they are so heavily reliant on compiler technology, they cannot afford not to. This is exactly what I was thinking, and it's even more true now that D has two fully open-source compilers. GDC is almost usable on x86 already. (Almost here means there's one showstopper bug that keeps me from using it for real work.) I'm sure you could hire a dev or two to get it working well on ARM and/or PowerPC. Think of all the money you'd save by not having to hire a bunch of extra people to write and maintain mountains of boilerplate. Remember: 1. You don't get the money until the job is done. 2. It has to be done on time. If you want to hire extra people then it comes out of your own money and you'll have to account for the time it would take to get all the tools working.
