> However, the last point was directed to the D community. The language needs to be more focused on being very good at some key areas, not cover everything.
I totally agree on this, but the problem here is that
there are game developers out there, willing to use D. I also see lots of movement from hobbysts. We can't ignore them completely. Undefinedly long pauses are really bad for them, and something needs to be done. Be it in user code, library solution or as core part of the language.

I agree that AAA titles are not the main right now, but this doesn't mean indie projects shouldn't be doable. After all, 150 milliseconds pauses are really annoying for pretty much any first person game.

On Sunday, 9 February 2014 at 20:15:51 UTC, francesco cattoglio wrote:
> I totally agree on this, but the problem here is that
> there are game developers out there, willing to use D. I also see lots of movement from hobbysts. We can't ignore them completely. Undefinedly long pauses are really bad for them, and something needs to be done. Be it in user code, library solution or as core part of the language.

I totally agree with you. I totally agree that the best focus for D would be to aim for towards being a kick-ass low level system language with programmer directed optimization (compiler hints), good memory layout control, and low latency, for medium sized code bases, and without historical c/c++ cruft. Because that spot is open and it rings a bell... For some reason the D community does not pursue it… as a shared goal. And that means D will never get there.

I think one needs profiled whole program analysis to get there. I think one needs to aim for upcoming hardware architectures. I think one need to back it up with programmer specified constraints and hints. I think one needs high level optimization in addition to low level. I think one needs a very light and transparent runtime with tuneable low cost allocation schemes.

I also think one needs to reduce the focus on separate compilation with no knowledge about what goes on inside an object file and C++/C ABIs. The compiler should have as much information available as possible.

Then you also need to slack on C#/Java features, reflection, programming in the large, garbage collection and enforced correctness. To stay focused. However the goal of D appears to be to blend all these thing in one big melting pot. That makes things move slowly in a manner where I have trouble seeing the vision.

So the outlook today appears to be that D is primarily useful for the in-between-spot which is really tools and perhaps some server stuff.

> I agree that AAA titles are not the main right now, but this doesn't mean indie projects shouldn't be doable. After all, 150 milliseconds pauses are really annoying for pretty much any first person game.

Yeah, it is indeed both uneccessary and undesirable with that kind of latency, but if it happens once per hour it has no real consequences in most scenarios. For some reason the GC is the holy grail of D, so I am just kind of figuring out what the benefits/damage is.

Personally I have given up all hope of D becoming useful for client side stuff:

1. because of all the resistance in the forum.

2. because C++ portability is hard to beat (android, ios, win, pnacl etc)

3. because C++ provides low latency

4. because the capabilities of HTML5 browsers are eating heavily into the client space and might change the landscape in a few years

I think the perceived D-vision-of-2013 might be useful on the efficient-server-side and there the GC actually makes sense every once in a while to clean up leaks.

And that is OK too, even thought that space is a bit more crowded than the low level space.

Just let's avoid the high profile argument. Be exceptionally good at some modest stuff first then expand into other areas next iteration.

I think the fallacy is the notion of General Purpose Programming Language, as if those actually exist. :-) They don't, because human beings are following trends and you need a focused culture to sustain the eco system.

So yeah, I agree with you, but I don't see the clearly communicated vision and therefore don't believe in the growth of a eco system around D for client side programming. :-/

On 9 February 2014 20:16, <"Ola Fosheim Grøstad\" <ola.fosheim.grostad+dlang@gmail.com>"@puremagic.com> wrote:

> On Sunday, 9 February 2014 at 10:06:12 UTC, Manu wrote:
>
>> I don't think you've mage a game recently.
>>
>
> Pointless comment.
>
>
>  Most big games are multi-year projects with teams numbering well in the
>>
>
> Most games are not big.
> Most games fail in the marketplace.


So D is an indy/mobile games language? Well, it certainly won't be that
until Android and iPhone is well supported.
AAA games however is technically possible right now, but needs more work
before it will appeal to the industry without objection.

 I didn't say they should be a focus, I'm saying they must however be
>> supported.
>>
>
> Must is a strong word, but since D is focusing on separate compilation it probably is a focus.
>
> Why are most comments about the application domain for D centered on "prestigious" projects such as AAA games, high volume trading system and safety critical appliations?
>

Perhaps it's because these are precisely the first few major businesses who
have made a commercial commitment to D?
If the language fails to satisfy ambitious early adopters, why should
others follow?

The most likely application domain is a lot less "exciting": tools and
> simple servers.
>
> Get down to earth, plz.
>

I don't write 'unexciting' tools and simple servers, so they are not my
focal points. There are plenty of other people here that keep those usage
targets in check.
There are relatively few (although numbers are growing surprisingly fast)
who keep the big-games, realtime, or embedded/resource-limited usage
targets in check. I'm one of them, and I want a future for D in my
industry. If it's declared that that's not a goal for D, then I will leave
the community on that day.
I am standing firmly on planet earth, and those jobs are what pay my bills.
I know the requirements of my industry.

On 10 February 2014 06:15, francesco cattoglio < francesco.cattoglio@gmail.com> wrote:

> However, the last point was directed to the D community. The language
>> needs to be more focused on being very good at some key areas, not cover everything.
>>
> I totally agree on this, but the problem here is that
> there are game developers out there, willing to use D. I also see lots of
> movement from hobbysts. We can't ignore them completely. Undefinedly long
> pauses are really bad for them, and something needs to be done. Be it in
> user code, library solution or as core part of the language.
>
> I agree that AAA titles are not the main right now, but this doesn't mean indie projects shouldn't be doable. After all, 150 milliseconds pauses are really annoying for pretty much any first person game.
>

The only company I know of that has made a commercial commitment to D is a AAA games company...

On 2/9/14, 1:06 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
[snip]
> I think one needs profiled whole program analysis to get there. I think
> one needs to aim for upcoming hardware architectures. I think one need
> to back it up with programmer specified constraints and hints. I think
> one needs high level optimization in addition to low level. I think one
> needs a very light and transparent runtime with tuneable low cost
> allocation schemes.
>
> I also think one needs to reduce the focus on separate compilation with
> no knowledge about what goes on inside an object file and C++/C ABIs.

Your thoughts are appreciated (all 6 of them in as many sentences). There is something to be said, however, about armchair quarterbacking and holier-than-thou kibitzing on what others should be doing. This community is as close as it gets to a meritocracy, so if you think you know what's good, you do good. If you want your stupendously many "I think"s to carry weight, follow them with some "I do"s as well. Hop on github. This endless walk through your knowledge base just isn't useful.


Andrei

On 10 February 2014 14:15, Manu <turkeyman@gmail.com> wrote:

> On 10 February 2014 06:15, francesco cattoglio < francesco.cattoglio@gmail.com> wrote:
>
>> However, the last point was directed to the D community. The language
>>> needs to be more focused on being very good at some key areas, not cover everything.
>>>
>> I totally agree on this, but the problem here is that
>> there are game developers out there, willing to use D. I also see lots of
>> movement from hobbysts. We can't ignore them completely. Undefinedly long
>> pauses are really bad for them, and something needs to be done. Be it in
>> user code, library solution or as core part of the language.
>>
>> I agree that AAA titles are not the main right now, but this doesn't mean indie projects shouldn't be doable. After all, 150 milliseconds pauses are really annoying for pretty much any first person game.
>>
>
> The only company I know of that has made a commercial commitment to D is a AAA games company...
>

Sorry, I obviously mean, "the only *games* company..."

150ms pause isn't only annoying, it's the sort of bug that might have your
title refused for release by the platform vendors.
And people seem to forget promptly after every single time I repeat myself:
 * The GC frequency of execution is directly proportional to the amount of
_free memory_. In console games; NONE.
 * The length of the associated pause is directly proportional to the
amount of memory currently in use. In console games; all of it.

This doesn't only describe games, it describes any embedded environment.

On Monday, 10 February 2014 at 04:26:10 UTC, Manu wrote:
> Sorry, I obviously mean, "the only *games* company..."
That was a given. However I think AAA titles have the manpower to avoid those pauses, since the amount of work toward optimization is huge anyway, am I right? Ofc you still need minimal backend from the compiler and runtime support. If you lack control on internals, there's no way for you to optimize anything.
> And people seem to forget promptly after every single time I repeat myself:
>  * The GC frequency of execution is directly proportional to the amount of
> _free memory_. In console games; NONE.
>  * The length of the associated pause is directly proportional to the
> amount of memory currently in use. In console games; all of it.
For "simple" games, it would be nice to have a better GC and cut down allocations from the standard library. I guess that would suffice, no need to move to ARC.

On Monday, 10 February 2014 at 04:22:32 UTC, Andrei Alexandrescu wrote:
> Your thoughts are appreciated (all 6 of them in as many sentences). There is something to be said, however, about armchair quarterbacking and holier-than-thou kibitzing on what others should be doing. This community is as close as it gets to a meritocracy, so if you think you know what's good, you do good. If you want your stupendously many "I think"s to carry weight, follow them with some "I do"s as well. Hop on github. This endless walk through your knowledge base just isn't useful.

Good job, my initial response to Manu was a critique of going Ad Hominem and you as a person time and time again fail in that regard in many discussions. You do however deserve a round of ad hominem because you as one of the two people who are in a position to communicate the project vision and set forth MEASURABLE goals that can be tracked and evaluated, but you refuse to do so.

All talk of meritocracy is essentially hypocrisy because all projects need to establish boundaries and a goal post, and you fail miserably in that regard. That's why D is a slow mover. "This endless walk through [my] knowledgebase" is of course not a walk through my knowledgebase, it is an assessment of the project that YOU FAIL to attempt to do. It is my attempt to try to figure out where this project is heading.

You are right, I should not have to do it. YOU SHOULD DO IT. AND PRESENT IT. That way people won't be let down.

I like the initial vision Walter Bright put forth years ago, that is to make a better C++. That has somehow evolved into making a compiled C#. Can you please ASSESS that.

You and Walter Bright are leads.

I expect any project and you to put forth:

1. A clear vision that establish a firm boundary.
2. A small set of clear measurable goals that give the project direction.
3. A list of points stating what the project is not going to address in the immediate future.

This endless walk through what is wrong with D project management just isn't useful, because you don't want to listen.

On 10 February 2014 17:58, francesco cattoglio < francesco.cattoglio@gmail.com> wrote:

> On Monday, 10 February 2014 at 04:26:10 UTC, Manu wrote:
>
>> Sorry, I obviously mean, "the only *games* company..."
>>
> That was a given. However I think AAA titles have the manpower to avoid those pauses, since the amount of work toward optimization is huge anyway, am I right? Ofc you still need minimal backend from the compiler and runtime support. If you lack control on internals, there's no way for you to optimize anything.


If we wanted to spend that time+manpower (read, money & overtime/sanity) on
bullshit like that, we have no reason to adopt D; we already have C/C++,
and we already have decades of experience mitigating that nightmare.
The point is, we are REALLY sick of it. Why would we sign up to replace it
with more of the same thing.

 And people seem to forget promptly after every single time I repeat myself:
>>  * The GC frequency of execution is directly proportional to the amount of
>> _free memory_. In console games; NONE.
>>  * The length of the associated pause is directly proportional to the
>> amount of memory currently in use. In console games; all of it.
>>
> For "simple" games, it would be nice to have a better GC and cut down allocations from the standard library. I guess that would suffice, no need to move to ARC.
>

For 'simple' games, might as well write then in Java or C#, the tooling is
much better, and support is offered by major multinational corporations.
Not to say that they shouldn't be supported in D too, but that's not a
target of interest to me, and I don't think it's an area which makes a
particularly compelling argument for adoption of D.
I've said before, console games is an industry desperate for salvation, and
D makes a very strong case here in lieu of any other realistic
alternatives... as long as this memory stuff is addressed acceptably.

If there were to be some killer potential markets identified for D, I think this is definitely one of them.

On Monday, 10 February 2014 at 04:26:10 UTC, Manu wrote:
>> The only company I know of that has made a commercial commitment to D is a
>> AAA games company...

Unfortunately a AAA games company is not setting down the goal post for D. As long as the leads for the project have as their primary interests: non-real-time stuff and STL-like-libraries things won't develop in your (and mine and Fransescos) direction.

It won't happen until the leads of the project COMMIT to a MEASURABLE goal and a major effort is made to meet that goal. That means putting other goals aside until that measurable goal has been met.

> Sorry, I obviously mean, "the only *games* company..."

Yeah, but that games company needs to commit to taking a lead role so that the goal post and vision changes in that direction.

> And people seem to forget promptly after every single time I repeat myself:
>  * The GC frequency of execution is directly proportional to the amount of
> _free memory_. In console games; NONE.
>  * The length of the associated pause is directly proportional to the
> amount of memory currently in use. In console games; all of it.
>
> This doesn't only describe games, it describes any embedded environment.

I've already stated that I don't believe in using D for anything multi-media.

It is not part of the project vision to be good at that from what I am seeing, and I am not going to believe it is going to be good for that until the project leads commit to measurable goals.

The leads believe in meritocracy, that means the project will flail around in any direction that is fun. That means there are no rails. There is no reason to pull or push a train that is not on rails. To get D to be a true better C++ you need a concerted effort.