Le 16/01/2012 01:23, Andrei Alexandrescu a écrit :
> On 1/15/12 11:42 AM, Kiith-Sa wrote:
>> I'm interested in game development using D, so I'll post my opinion.
>>
>> I think the discussions here show how particularly specialized people
>> here are. I've seen some Manu's posts and it was clear that he is a
>> person
>> in gamedev who thinks most development is like gamedev and can't see
>> the bigger
>> picture. For a gamedev person, SIMD support is not simply a cool
>> feature, it's
>> a gamechanger. Just like const, ranges, D threading features and so
>> on. However,
>> his posts often show that he doesn't understand positions of other
>> people in other
>> areas, e.g. people here working on scientific computing, who are also
>> interested
>> in SIMD but their thinking of terms such as "vector" is completely
>> different.
>>
>> I think you're making the same mistake here - you have very little (or
>> no?)
>> idea about gamedev and aren't exposed to game programmers, so you just
>> assume
>> specific gamedev issues don't exist or are unimportant. I don't think
>> you get
>> much of exposure to game devs when evangelizing D either - you don't
>> evangelize
>> D in game companies.
> [snip]
>
> You are making a good point, and I'm glad you chimed in.
>
> I do have ties with the gaming community; I taught a course at ENDI and
> I am well acquainted with a few game developers. Also, at conferences
> and events gaming programmers are represented. Finally, game developers
> who are reading TDPL are likely to send me book feedback and questions
> in proportion to their representation. From where I stand, I can say
> there is more interest in D in other communities than in gaming.
>
> Clearly gamedev-specific issues do exist and are important. But that's
> not even remotely the point. Allow me to explain.
>
> Say we identified gaming programmers as an important community to
> address. If that happened, we would have done a /lot/ of things
> differently, and a ton of them before SIMD. That means focus on
> Windows64, graphic accelerators, and gaming CPUs. To claim that work on
> SIMD is good because it's good for gamers is to reverse engineer a
> rationalization after the fact. And the fact is - Walter has had the
> gusto to implement SIMD now. Technically, that's great. For gamers,
> that's an interesting development. Organizationally, that's a poor
> statement.
>
> Again: if D is a hobby we have, all's great. Otherwise, we must show
> people that we are serious about finishing the core language
> implementation, that we make promises that we are able to keep, and that
> we make plans that we follow even in the broadest strokes. If we want to
> play with the big boys, we need to change the way we approach planning
> and organization quite drastically.
>
>
> Andrei

To add more to the point, game develloper also face the core language. const or even worse shared issues are very important to game devellopers (you need a good threading support to code a game engine that exploit modern CPU, and to not choke on IO). So core languages feature bugs also affect game devellopers.

Le 17/01/2012 11:52, Walter Bright a écrit :
> On 1/17/2012 2:07 AM, Gour wrote:
>> My example was just meant to show what might be the result when one
>> feels that developers are not behind their product in a sense that one
>> 'cannot count on the project' which was supposed to be continuation on
>> my "we always get the feedback it's not safe investment of our time&
>> energy and it would be better to use something else, either C(++), Java,
>> Scala, Python etc."
>>
>> So, I highly admire the work of all members within D community giving
>> something valuable for free, but being interested in success of D, I
>> wanted to share my experience I have when trying to advocate using of D
>> for real (open-source) projects *today*.
>>
>> I'll try to be more sensitive next time...
>
> I'm not taking issue with sensitivity, just that one is *less* likely to
> get responsive bug fixes from Major Software Vendor, and so dismissing D
> for that reason is invalid.
>
> I've seen people say "D doesn't have feature X, so I'm going to use
> language B." But B doesn't have feature X, either. Again, the reason
> given is invalid.
>
> The real issue is something they're not telling you. The trick is
> finding out the real issue, which can take some insight. Otherwise,
> you'll waste a lot of effort chasing rainbows.
>
> Sometimes, the real issue is "nobody ever got fired for buying IBM." You
> could fix every issue on their list, and you still won't close the deal,
> because you are not IBM. You cannot please everyone, it's better to
> recognize who you *can* close the deal with (there's always someone who
> is not impressed by IBM), and work on their issues rather than the
> rainbows and smokescreens.
>
> That means focus on what we are good at.

Switching has a cost in itself. To trigger change, you don't need to provide something more, but that is not enough. You need to provide enough to make the benefit of switching bigger than the cost that comes with swithing.

And that is only if you are rationnal. If you consider basic psychology, you'll notice that effect like cognitive dissonance and you'll notice that things are even worse. This is not fair, I do agree, but this is the world we live in.

As a last point, I'll mention that using D has obvious drawbacks : lack of documentation, lack of support, not that many exemple, compiler bugs, limited IDE integration, limited toolchain, etc . . . So this is rationnal to choose another language if both have the needed feature.

On 01/18/2012 09:22 PM, deadalnix wrote:
> To add more to the point, game develloper also face the core language.
> const or even worse shared issues are very important to game devellopers
> (you need a good threading support to code a game engine that exploit
> modern CPU, and to not choke on IO). So core languages feature bugs also
> affect game devellopers.

Much less so than SIMD support. Type system features like const or shared may help but are not necessary at all for creating an efficient game engine. (in fact, an efficient engine will maximize parallelism while keeping concurrency at a minimum.)

But then, I am not a professional game developer. Is there any game developer frequenting this NG who thinks const/shared are more important than SIMD?

On 1/18/2012 12:30 PM, deadalnix wrote:
> Switching has a cost in itself. To trigger change, you don't need to provide
> something more, but that is not enough. You need to provide enough to make the
> benefit of switching bigger than the cost that comes with swithing.
>
> And that is only if you are rationnal. If you consider basic psychology, you'll
> notice that effect like cognitive dissonance and you'll notice that things are
> even worse. This is not fair, I do agree, but this is the world we live in.

I fully understand that and agree with it. That is why I am often skeptical of the reason given for not switching - my experience is that it is likely not the real reason. It takes some digging and insight to get at the real reason.

Not understanding the real reasons leads us to waste effort solving the wrong problems.


> As a last point, I'll mention that using D has obvious drawbacks : lack of
> documentation, lack of support, not that many exemple, compiler bugs, limited
> IDE integration, limited toolchain, etc . . . So this is rationnal to choose
> another language if both have the needed feature.

Those are drawbacks, indeed, but sometimes are given as rationalizations for what might be other reasons entirely.

For example, let's assume we're talking to an expert Java developer. He has spent the last 10 years becoming an expert in every detail of Java. He's at the top of the Java community, and at the top of his game. Is he going to switch to D? Pretty unlikely, as now he'd be discarding a big chunk of that hard-won, valuable expertise. Is he going to give that as the reason for not switching? Not a chance.

(Andrei is a remarkable exception.)

We can beat ourselves to a bloody pulp trying to entice them to switch, or we can engage more fertile ground, which are the newer developers who haven't set their careers in concrete yet. And this is the way it always is for new technology adoption.

On 1/18/2012 12:10 PM, deadalnix wrote:
> Usually, a newcomer isn't even sure if the bug comes from his/her code or from
> the compiler. How can you expect them to fill a bug about the spec ???

That's what these forums are for - to ask.

On Wednesday, 18 January 2012 at 20:41:14 UTC, Walter Bright wrote:
> On 1/18/2012 12:10 PM, deadalnix wrote:
>> Usually, a newcomer isn't even sure if the bug comes from his/her code or from
>> the compiler. How can you expect them to fill a bug about the spec ???
>
> That's what these forums are for - to ask.

You don't think that lowers the probability of someone wanting to use D?

How about putting equal effort in keeping existing D users? There is more than one blogs online of ex D users with some pretty solid arguments why they abandoned D. And those args are usually not some missing shiny feature X but feature Y D already has but it is broken.

Just saying focusing on bright future is not excuse to forget about imperfect now.

On 1/18/2012 1:12 PM, Zachary Lund wrote:
> On Wednesday, 18 January 2012 at 20:41:14 UTC, Walter Bright wrote:
>> On 1/18/2012 12:10 PM, deadalnix wrote:
>>> Usually, a newcomer isn't even sure if the bug comes from his/her code or from
>>> the compiler. How can you expect them to fill a bug about the spec ???
>>
>> That's what these forums are for - to ask.
>
> You don't think that lowers the probability of someone wanting to use D?

What do you suggest?

On 1/18/2012 1:27 PM, Patrick Stewart wrote:
> How about putting equal effort in keeping existing D users? There is more
> than one blogs online of ex D users with some pretty solid arguments why they
> abandoned D. And those args are usually not some missing shiny feature X but
> feature Y D already has but it is broken.

I do attach far more importance to that than to reasons people who never used D do not use D.


> Just saying focusing on bright future is not excuse to forget about imperfect
> now.

I'm not saying it is.

The point is, we have limited resources. We have to put those resources where they will have the most effect.

On 18/01/12 9:55 PM, Walter Bright wrote:
> On 1/18/2012 1:12 PM, Zachary Lund wrote:
>> On Wednesday, 18 January 2012 at 20:41:14 UTC, Walter Bright wrote:
>>> On 1/18/2012 12:10 PM, deadalnix wrote:
>>>> Usually, a newcomer isn't even sure if the bug comes from his/her
>>>> code or from
>>>> the compiler. How can you expect them to fill a bug about the spec ???
>>>
>>> That's what these forums are for - to ask.
>>
>> You don't think that lowers the probability of someone wanting to use D?
>
> What do you suggest?

Well, it's kind of too late now, but ideally the implementation and documentation should have evolved together, so that the situation we are in now wouldn't have happened.

What happened instead was an incomplete spec popped up with no implementation then the implementation tried to match it, whilst changing parts of it (without updating the documentation) along the way. We also now have the TDPL, which in parts disagrees with both the implementation and the original spec.

What we can do now:

1. Hope that people are knowledgeable and willing enough to update the documentation to match the current language state.

2. Ensure that any submitted pull requests into DMD that change language features are also documented in the language spec at the same time. Recent example: array covariance changed, but the language spec didn't. I'm working on a pull request to fix the spec now.

We have to be much more diligent about keeping the spec up to date.