On 10 February 2014 22:00, Szymon Gatner <noemail@gmail.com> wrote:

> On Monday, 10 February 2014 at 10:53:05 UTC, Manu wrote:
>
>
>> I left Remedy a year back, so I don't speak on their behalf anymore. Is that what you mean?
>>
>>
> Sorry for being OT, but where do you work now?
>

I'm very happily unemployed! :) ... but that'll probably have to change
some time soon.
Might have to move country again, not much happening in Australia anymore
after the near total obliteration of the industry here that devastated most
of my friends and colleagues.

On Monday, 10 February 2014 at 10:04:53 UTC, Francesco Cattoglio wrote:
> On Monday, 10 February 2014 at 08:59:28 UTC, Ola Fosheim Grøstad wrote:

>> 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.
> No, first of all you need the same amount of economic backing. The one backing the project will shape it the most. True democracy is pure utopia. People have different interests and different ideas, which are often conflicting. In the end it's all about resources.

I forgot to comment on this.

No, I don't think it is only a matter of resources. For instance, if I had the time I would most certainly consider writing a pack-rat parser for a modified subset a D that builds an AST for clang.

That's actually doable for 1-3 people.

On Monday, 10 February 2014 at 14:24:06 UTC, Ola Fosheim Grøstad wrote:
> No, I don't think it is only a matter of resources. For instance, if I had the time I would most certainly consider writing a pack-rat parser for a modified subset a D that builds an AST for clang.

"if I had the time". This exactly is the difference and reason why resources matter a lot.

On Monday, 10 February 2014 at 14:47:15 UTC, Dicebot wrote:
> "if I had the time". This exactly is the difference and reason why resources matter a lot.

Yes, but there are enough people in these forums claiming that they desire a real time, production quality, better-than-c++ compiler to pull it off. But not for me alone.

Lack of clear planning, communication of visions and establishing short term and long term measurable goals is not really a resource issue. It is a matter of taking those issue seriously. Basically a management issue.

To me it would be reasonable to have:

1. short term goal: production level stability for what D is being used for today

2. long term goal: low latency, real time features/runtime

Then work on 1 while planning milestones for point 2.

I guess D1 was supposed to address 1, but nobody would start a project from scratch using D1 today.

Le 09/02/2014 11:16, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" a écrit :
> 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.
>
>> 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?
>
> The most likely application domain is a lot less "exciting": tools and
> simple servers.
>
> Get down to earth, plz.

Maybe if performances are not really critical, developers can already use Java or C# with a GC?
IMO D have to target all applications have to be written in C/C++, where performances or portability, scalability,... are critical.
Java and C# developers already have a lot of good tools that C/C++ developers doesn't have, we need love too :-)
D claims to be a system language so it's normal to expect to be able to use it on critical ways easily, and maybe lesser for simple applications can already done with actual proven technologies.

D is already more complicate to use than Java or C#, just take a look of keywords,... but it's not surprising for a system language with advanced features than other languages doesn't support.
IMO D programmers want have a great control on memory even if it can be a pain.

We can let D satisfy ego of few developers doesn't already have the need of a such language on some points since it is already much less error prone than C++. :-)

Le 09/02/2014 21:15, francesco cattoglio a écrit :
>> 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.

With a pause of 150ms, you just can't play an animation of any kind. A lot of sample application like a movie play will require to use threads just cause of a GC? I don't find that simple.
It's the same for GUI application, having 150ms of pause after a button hit can be horrible, again I don't think it has to be necessary to thread all UI applications even if it's simpler with a language like D.

On Monday, 10 February 2014 at 21:17:22 UTC, Xavier Bigand wrote:
> Maybe if performances are not really critical, developers can already use Java or C# with a GC?

Or javascript actually, if you use the animation capabilities of the browser engine…

> IMO D have to target all applications have to be written in C/C++, where performances or portability, scalability,... are critical.
> Java and C# developers already have a lot of good tools that C/C++ developers doesn't have, we need love too :-)
> D claims to be a system language so it's normal to expect to be able to use it on critical ways easily, and maybe lesser for simple applications can already done with actual proven technologies.

I share your views actually… so I trying to take the view that D is not a C++ replacement, but a compiled C#. That makes it much easier to accept the current state. :-)

I am no longer sure if I am able to view D as a system language. Too many features that are not really important on the low level. Too big runtime. And no strategy that points towards whole program optimization. I'd personally much prefer less features, more performance control and whole program optimization.

I distinctly remember doing profiling based whole program optimization of c-programs on unix machines in the 1990s. Seriously, that's 18+ years ago.

Am 10.02.2014 22:23, schrieb Xavier Bigand:
> Le 09/02/2014 21:15, francesco cattoglio a écrit :
>>> 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.
>
> With a pause of 150ms, you just can't play an animation of any kind. A
> lot of sample application like a movie play will require to use threads
> just cause of a GC? I don't find that simple.
> It's the same for GUI application, having 150ms of pause after a button
> hit can be horrible, again I don't think it has to be necessary to
> thread all UI applications even if it's simpler with a language like D.
>

A bit off topic, but can you still get new single core chips?

Le 10/02/2014 09:58, Manu a écrit :
> On 10 February 2014 17:58, francesco cattoglio
> <francesco.cattoglio@gmail.com <mailto: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.

Like you I don't see the interest for D to compete against C# or Java. IMO there is a big hole that C/C++ developers dream to see filled.
We want :
 - a less error prone language : DONE
 - a better syntax : DONE
 - advanced meta-programming features : DONE
 - a fast build : DONE
 - a rich framework : Have some potential (miss a lot of QtCore equivalent, GUI libraries), progress really slowly
 - be multi-platform : almost DONE
 - be cross-platform (binary portable) : a potential way with LVM bytecode
 - no performance concessions : GC issues
 - better tools (IDE with refactor tools working, better debugger,...)
 - buildin tools (unittest, static analyser,...) : DONE

For the moment D GC was a real pain for me on DQuick, I am not able to control when releasing my OpenGL resources easily. I can't wait a GC collect, cause handles are fewer than the central memory. The destruction order is also a real issue. I certainly have to learn new patterns, but I try to add a release method on Resource objects and add a check in debug to see if it was correctly called. I wasn't able to use Throwable.TraceInfo cause it's a class which means can't be printed in the destructor. So if a user forgive to call release method on a resource (leak) I just can't warm him with a great message...

For me leaks aren't just unreferenced pointers, but also and mainly chunk of resources still retained when not necessary cause those are harder to track and are critical on small devices. A GC won't help you a lot here, because IMO it act like a pool on every objects. It seems a lot of developers aren't concern by memory usage when there is a GC.
I am also concern of having all applications using a GC, cause it force user of multi-task OS to buy more memory or close few applications.

I just buy 4Go more cause I can't let my smartgit,VS,Chrome,... when playing Battlefield 4???. Smartgit is in Java, VS in C# in a part and Chrome create a process per tab???
Please stop pushing us create applications memory consuming, it's not cheap.

---

Maybe D is too ambitious, what we really need is a language that can be updated more easily than C++ to be as soon as possible usable in industry.

Seriously I work for a little game company, we are few developers (about 9 developers on 3 different projects), we don't have means to use IncrediBuild or such tools to save times. Reducing the compile time and having a great framework are critical points for us. We have relatively few memory issues by managing it ourselves.

We use C++ cause our targets are numerous :
 - Windows Pocket PC : not anymore
 - Symbian : not anymore
 - Nintendo DS : not anymore
 - Nintendo Wii : not anymore
 - iOS
 - Windows
 - MacOS X
 - Android
 - Xbox 360
 - PS 3

Our applications/games can have some critical performances aspect, but we don't have to optimize all our code, cash misses are accepted :-) Our optimization are essentially high level or only concern the OpenGL render, maybe some few algorithm like simple occlusion, tiling,...

Sadly for next games we didn't use our internal game engine but Unity 3D. We made some test on doing a scene like those of RTMI (http://www.youtube.com/watch?v=fGtfhKrg3l0) on Unity without success, cause of specific optimizations required for animations done with a lot of textures updates.

Editors prefers Unity cause of C# that is synonymous of standard tools and easier to regain control by other developers.

On Monday, 10 February 2014 at 14:24:06 UTC, Ola Fosheim Grøstad wrote:
> No, I don't think it is only a matter of resources. For instance, if I had the time I would most certainly consider writing a pack-rat parser for a modified subset a D that builds an AST for clang.
>

You do that :D

I'll be waiting. Some people just need to run into the roadblock to notice it exists.