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.

"Xavier" <xman@nospam.net> wrote in message news:j51p5q$2utg$1@digitalmars.com...
>
> "Nick Sabalausky" <a@a.a> wrote in message news:j51m0l$2prg$1@digitalmars.com...
>>
>> In both this and your other post, you're conflating the notions of the "language quality" vs "implementation quality". The two are not the same.
>
> They are not necessarily orthogonal though either. Surely you are just focusing on design and maybe semantics and maybe even syntax, but those aren't the only criteria and of those things, C++ and D have more in common than they have not in common. For instance, if implementation quality is bad, maybe the language's implementability is bad. If so, then it's a language "quality" issue. Now you can argue that C++ is much worse in regards to implementability, but that doesn't really say anything more than something like "D is better than the POS that C++ is". To be markedly different from C++, D would have to be thought of as being in a different category than "which is the better POS?", but of course it cannot, for it comes from the same family, "one generation newer than C++".
>
>> Now, yes, D effectively has one implementation (the DMD frontend), but even considering that, the notions are still worth separating:
>>
>> For one thing, implementation quality is much easier to improve than language quality.
>
> That may be true if one had a language that indeed was at some superior design level, but D is not at that level. It's at the same level as C++ is, so there is major room for improvement (i.e., requires a different language) in a number of areas.
>

What you're ultimately saying is that if a guitar has a crappy first and second string (and therefore sounds lousy), then you also have to replace the other four strings, the pickups, the head, the body, the amp, the neck and the carrying case to make it sound good again. Replacing the two crappy strings won't be enough to make it sound significantly better.

What you're missing is that a minority portion *can* ruin a whole. If you consider D and C++ to be mostly the same, then C++ is crappy because of, what you're perceiving to be, a minority subset of it's design. D cuts out the cancer and saves the whole.

Your notion that a big imporvement requires a big change is just plain false.


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

You know perfectly well those were just examples.

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

1. IDE features are not substitutes for language improvement.

2. Such features don't end up in a IDE "for free". There's cost associated with actually putting them in there for a given language. You're not factoring that in. Additionally, this also implies that not everyone always has such features available.


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

Yes, because if one boat starts sinking, they're all about to start sinking...

And if you felt sick due to kidney failure, you'd insist that replacing the kidney will just make you slightly less sick. So you'd insist the doctor also replace your heart, your hip and your leg, fuse your spine, perform brain surgery, die your hair, and give you glasses, dentures and a facelift...

"David Nadlinger" <see@klickverbot.at> wrote in message news:j51nfi$2rjc$1@digitalmars.com...
> On 9/17/11 10:51 AM, Nick Sabalausky wrote:
>> I almost wish it were. Then I could just say, "No, it's like this..." Problem solved. Or better yet, "Go make me a sandwich." Better problem solved :)
>
> Have you tried using »sudo go make me a sandwich«? ;)
>

XKCD FTW :)

Absolutely fantastic comic.

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

- Bunny
- Extra Life
- VG Cats
- Sexy Losers (NSFW, although I'm not sure it's even around anymore)
- Perry Bible Fellowship (not at all what it sounds like)

"David Nadlinger" <see@klickverbot.at> wrote in message news:j51nfi$2rjc$1@digitalmars.com...
> On 9/17/11 10:51 AM, Nick Sabalausky wrote:
>> I almost wish it were. Then I could just say, "No, it's like this..." Problem solved. Or better yet, "Go make me a sandwich." Better problem solved :)
>
> Have you tried using »sudo go make me a sandwich«? ;)
>
> David

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

http://xkcd.com/149/

-=mike=-

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?

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

On 17/09/11 6:53 AM, Nick Sabalausky wrote:
> "Peter Alexander"<peter.alexander.au@gmail.com>  wrote in message
>> For example, if the job was to produce a AAA video game that ran on PC,
>> PS3 and XBox 360, I'm sure you could *do it* with D if you paid people to
>> develop the compiler tech and tools to produce PowerPC code and interface
>> with all MS's and Sony's libraries and tools. But would you?

> People who are *good* at C++ are hard to find, and even harder to cultivate.
> And that's never going to change. It's a fundamental limitation of the
> langauge (at least until the Vulcans finally introduce themselves to us).
> But D's a lot easier for people to become good at.

You don't need people that are especially good at C++. You don't need to know metaprogramming or generic programming or the intricacies of templates to ship a product.

Just look at the DMD compiler: there's no advanced C++ in there at all. It still works.


> And then there's the enurmous savings in build times alone. Full recompiles
> of AAA C++ games are known to take upwards of a full day (not sure whether
> that's using a compile farm, but even if it is, D could still cut down on
> compile farm expenses, or possibly even the need for one).

This is false. You can easily build several million lines of code in several minutes using unity files and distributed building. There need not be any build farm expenses, the build machines can just be everyone's dev machines.

In contrast, my D hobby project at only a few thousand lines of code already takes 11s to build and doesn't do any fancy metaprogramming or use CTFE. I am unaware of any distributed, incremental build systems for D, so I see no particular speed advantage to using D (certainly not orders of magnitude anyway).


> I'm sure there are smaller reasons too, but I'm convinced the primary reason
> why AAA game dev is C++ instead of D is ultimately because of inertia, not
> the languages themselves, or even the tools (If the AAA game dev industry
> genuinely wanted to be using D, you can bet that any tools they needed would
> get made).

Tools are not free. Don't assume just because a company is large that it has unlimited funds. Creating tools, converting libraries all take lots of time and money that have to be justified.

I work at a very large game studio and I can assure you that I would *never* be able to justify using D for a project. Even if all our code magically transformed into D, and all our programmers knew D, I still wouldn't be able to justify the creation of all the necessary tools and dev systems to do something that we can already do.

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

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.

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