"Xavier" <xman@nospam.net> wrote in message news:j51jsp$2lln$2@digitalmars.com...
>
> "Nick Sabalausky" <a@a.a> wrote in message news:j51h52$2h0e$1@digitalmars.com...
>> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.2921.1316239886.14074.digitalmars-d@puremagic.com...
>>> On Saturday, September 17, 2011 01:53:07 Nick Sabalausky wrote:
>>>> People who are *good* at C++ are hard to find, and even harder to
>>>> cultivate.
>>>> And that's never going to change. It's a fundamental limitation of the
>>>> langauge (at least until the Vulcans finally introduce themselves to
>>>> us).
>>>> But D's a lot easier for people to become good at.
>>>
>>> It's a _lot_ easier to find good C++ programmers than good D programmers,
>>
>> Oh, definitely. But what I meant was that good D programmers can be cultivated. People can learn to be good at D. And while the same might *technically* be true of C++, the curve is so steep that it may as well be "what's out there is what's out there". It's, more or less, a non-renewable resource.
>
> It's not nearly as "steep" as it used to be, for C++, the tools, the techniques, the documentation, the users have matured and one need not struggle through everything on one's own anymore while learning it, but rather just go look up or ask for the answer, and it is still improving. Sure, if one exploits every "stupid template trick" and similarly with the other language features, then you will have "steep", but it is quite tractable these days if one isn't overzealous and able to separate all the jabber about "metaprogramming" and the like from the meat of the language. It will always have its warts, but D has many of the same ones.
>

In other words, "C++ is easy^H^H^H^Hless hard than it used to be, as long as you don't use any of the advanced features that are already trivial in D anyway."


>> I realize I've said this other times in the past, but I find that the compiler bugs in DMD are much less severe than the language deficiencies of a fully-bug-free C++ implementation.
>>
>
> That's an interesting, if not odd, statement considering that C++ are more alike than they are different.
>

I don't understand what you're saying here. Did you mean "D and C++ are more alike than different", or "C++ implementations are more alike than  are different". Either way, it doesn't make much sense.


>> Plus there's the idea of investing in the future to keep in mind: It's like the old quote: "I may be fat, but you're stupid. I can excersise and diet, but stupid will always be stupid."
>
> The truth of the matter is, though, that she won't exercise to any significant degree and has been on a diet her whole life and her weight has continually increased. On top of that, the fact that one can study, research and learn escapes the fat dumb blonde bimbo because she indeed is stupid, and that's why her "dieting" causes her to gain weight instead of lose it.
>

You've just completely broken the analogy because D's bugs *DO* get fixed. And they're getting fixed rather quickly now, too.


>>  D may have some bugs, but investing the effort to deal with them will
>> lead to further improvements. Dealing with C++'s problems, OTOH, will
>> hardly do a damn thing.
>
> Again, I find that a curious statement for reason noted. The language names even fit together: C/C++/D. There is no denying that they are all related. Just look at those noses! C'mon!
>

Umm, yea, they're related. So what? Don't tell me you're trying to imply that just because they're related they're inherently equal in everything but implementation.


>> Sure, a few things can be mitigated somewhat, such as the C++0x^H^H1x^H^H2x^H^H3x improvents. But in general, investing the effort to deal with C++'s shortcomings won't lead to significant improvements - it *can't* because it's constrained by its existing legacy design (not that that won't eventually happen to D, too, but D is one generation past C++).
>
> One generation away, but still the same family. So what?
>
>>  Ie., D may be buggy, but C++ is crappy. Bugs can be fixed, but crappy
>> will always be crappy.
>
> All adolescents conflict with their parents and say things like that. When D grows up, the D++ or E kids will be maligning D and then D will remember back how it was just the same when it was just a youngster.
>

Are you seriously trying say that that implies each successive one is inherently no better than the previous? If so, then that's just patently absurd. If not, then what in the world *is* your point? Just to troll?


>>>
>>> I definitely prefer D to C++, but I honestly think that your hatred of
>>> C++
>>> (which you have expressed on several occasions) clouds your judgement on
>>> the
>>> matter.
>>
>> FWIW, I had been a huge fan of C++ for many years and used it extensively ('course, that was quite awhile ago now...). And I *do* think it was a great language back in it's time. I just think that time is long since past.
>
> I think C++ is now coming into it's own and it sucked in the past much more. D is now in it's sucky period IMO, and may have it's day in the future. Time will tell.
>

Well, like I've said, I'd rather something with better language design and a few implementation worts, than something with inferior language design and perfect implementation.


>> When I say "C++ is crappy", I mean "within today's context, and moving forward from here".
>
> Tomorrow is surely something else, probably not D, IMO, but today is all C++.
>
>> I'm certainly aware of all that, and I do understand. But the question here wasn't "Do you think OTHER people feel language X is suitable for serious work?" It was "Do YOU think language X is suitable for serious work?" I don't doubt other people would disagree with me (especially people who haven't used D, and even probably some who have), but my own answer is "Yes, I think D is suitable for such projects, and in such a situation, yes, I would be willing to put my money where my mouth is."
>
> Ha! I inadvertently just answered those questions. Well, I guess you know what I think now (not that I was going to hide it).

You mean that you're just here to troll?

"Xavier" <xman@nospam.net> wrote in message news:j51kmt$2n7t$1@digitalmars.com...
>
> "Nick Sabalausky" <a@a.a> wrote in message news:j51ef3$2a0d$1@digitalmars.com...
>> "Xavier" <xman@nospam.net> wrote in message news:j50v3o$1gbb$1@digitalmars.com...
>>>
>>> I think the public schools are "teaching" "how to be a sheeple". What other reason could there be?
>>
>> Although I probably have about zero business sense, I absolutely agree on this part of what you said.
>>
>> At one point, I went to Bowling Green State University, well known to be an "accept anyone and everyone even if we don't have enough room" party school. Most of the students there generally thought for themselves (even if most of them weren't particularly bright.)
>>
>> Then I transfered to John Carroll University: a private school that, well, it's no Ivy-league, but it's fairly well-regarded, at least around the Cleveland area. Unlike BGSU, JCU is known to be fairly selective. But the vast majority of JCU students were complete mindless sheep. I'm being completely honest when I say it was actually somewhat disturbing how sheep-like they were. Of course, they were also just as dumb as the BGSU students, but unlike BGSU, most of them were uppity, conceited and had a noticeable tendency to mistake slogan and lecture regurgitation for intelligence, ability and independent thought.
>>
>> Conclusion: High schools specifically cultivate sheeple, which is a quality preferred by "respectable" colleges.
>>
>> I couldn't begin to speculate on why it's this way, or whether or not it's intentional by anyone who's still around. But whatever the reason, that's definitely how things are.
>>
>
> The most surprising thing to me is that it seems to work! It could be that most people simply are not very smart from the get go so they believe everything they read and are told and trust anyone and everyone. That's not it.

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

> (Well at first it may be, but surely at some point one becomes able to discern information of value from BS). It's not an intelligence thing. It's something else. I think I know what it is, but this is not the place to get into it. I do think that some of it shows thru a little in some of my posts. Then again, maybe the fat blonde bimbo is skinny now and I'm still stupid. Nah, that's not it. Certainly not.
> 

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.

On 9/17/11 10:51 AM, Nick Sabalausky wrote:
> I almost wish it were. Then I could just say, "No, it's like this..."
> Problem solved. Or better yet, "Go make me a sandwich." Better problem
> solved :)

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

David

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

Don't feed the troll.

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

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

> Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating:
>
> For one thing, implementation quality is much easier to improve than language quality.

That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas.

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

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

>
> So no, it's NOT a contradiction that D can be a better language while still having implementation issues.

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

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

Well, my pragmatic and simplistic definition of language quality is how fast work is done using that particular language. And in my experience I get hella lot of more work done in less time in D.

>
> Yes C++ is crap, but so is D, they're both crappy in their own ways,

What matters is the amount of crap. And D wins that game.

> to suggest otherwise is to assume that you're so much more intelligent
> than all that have come before you that you've managed to create a
> perfect product when all else have failed.

D has the advantage of hindsight. One is always more intelligent afterwards, so assuming that one knows more than the ones before is realistic. That is how progress works.

> To make analogy, it's like
> saying that OOP is inherently better than any paradigm before it.
>
> Ultimately though the issue is that C++'s crap is well explored and
> known, D's crap is significantly less so. Whether this is an issue for
> you depends entirely on your context.

Exploring crap is lost time. (and you stink afterwards, ftw!) If a language forces you to explore it's crap well to save your legs from being blown off, that is quite poor imho. You have to know what _works_.

"Josh Simmons" <simmons.44@gmail.com> wrote in message news:mailman.2922.1316246434.14074.digitalmars-d@puremagic.com...
> On Sat, Sep 17, 2011 at 5:30 PM, Nick Sabalausky <a@a.a> wrote:
>>
>> Keep in mind, most of a AAA game's codebase is externally-developed middleware these days. I think the middleware development sector would be willing to fix those issues if it meant being able to provide a more competitive offering (ie, their customers can use an easier to use/learn language, and don't need as many C++ gurus, etc).
>>
>
> You need high performance code gurus, the need for C++ people in non-performance critical code is already alleviated by the scripting world.
>

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


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

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


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

Yea, I suppose engine would be the key one.


> All of these layers need to be highly tuned for performance across many platforms including the console world.
>
> At this level the switch to C# provides much more than a 5% performance hit too, it makes the whole thing unfeasible. My feeling is that the same is true of D due mostly to immature tooling.
>

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


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

Oh, absolutely. Totally agree. In fact that's where I am...Or...would be...if I wasn't stuck in this perpetual web-dev hell...

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

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

I don't need intellisense, I'm fine with emacs. And compiling D code is usually so much faster than compiling C++ code that it is not even funny. Recompiling is not costly at all.

> That one thing is not as big an issue and certainly it pales in
> comparison to other language design flaws, which C++ and D both share.

Exactly which flaws are you talking about? Either get concrete so that your statements can be discussed and someone gets smarter in the process or stop making noise please.

>
>>
>> So no, it's NOT a contradiction that D can be a better language while
>> still having implementation issues.
>
> Anyway, you can talk until you are blue in the face, but you can't
> convince me that D and C++ aren't in the same category (as far as
> language design goes).

Well, nobody wants to convince you that D and C++ don't belong to the same category. (as far language design goes). Whatever that means to you.

But talking is worthless indeed. All your arguments are based on the wrong assumption that C++ and D are basically equal.


> You can call C++ a POS, but then, to me, that
> means that at best, D is just a better POS. But not to end this post on a
> bad note/word, I admire C++ a little bit. I certainly don't hate it.

Hating C++ is not a requirement for liking D better. Actually writing some lines of D code on the other hand, is.

> I can deal with it's shortcomings for now, so I could probably deal with
> D's also, but if I was thinking about jumping ship, I'd be swimming
> toward an island and not another ship.
>

If I want to reach an island, I usually don't swim. I take a ship that gets me there.