On 9 September 2013 05:46, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:

> On 9/8/13, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:
> > I realize that we want to make it as painless as possible for Remedy to switch from C++ to D (along with the rest of the game developers).
>
> FWIW I don't think this has anything to do with Remedy (afaik Manu
> doesn't work there anymore).
>

Indeed. These opinions are my own, and I raised it on the merit of our
experience last weekend in a 48hour game-dev-jam with a few former
colleagues (including one who still works at Remedy).
This discussion has come up at remedy in the past, but I don't think this
is of particular significance to the remedy workflow; the modules were
small enough to not cause issues, at least not as I left it.

I believe the scenarios I describe are going to be very typical though, at least in the game-dev context, particularly when larger volumes of D code emerge. I've demonstrated this across 2 separate 48 hour game-jam's now, which simulate the environment of a commercial crunch period quite faithfully.

On Monday, 9 September 2013 at 03:46:23 UTC, Manu wrote:
> For the record, I tend to agree with the arguments of many in the 'against'
> camp *from a purist point of view*, but the problem remains, and the reason
> I raised it; this has demonstrated to me and my colleagues on a number of
> occasions that it is a consistent productivity hindrance.

I think that you guys being experienced C++ devs makes it worse. As a matter of fact, changing an habit is difficult.

I suspect your experience here was in fact a source f increased difficulty. Let me take an actual example. When you put a total newbie in front of a linux or OSX, they usually manage pretty well (considering they are newbies). Now take the average windows user and put it in front of a linux or an OSX, and you'll notice that they have tremendous difficulties to use them. Because everything they know, every expectation they have, get into their way.

Anyway, this outline, first, the need of better IDE support (but that isn't big news, I guess we all know that by now). Second some need of interface/implementation separation.

For that second, it has been discussed in the thread to improve the di behavior to fit that role. Do think this is a viable approach, and that your team of happy devs would have benefited from that ?

 This seems like a waste of time compared to the other complaints Manu brought up(bad IDE/debugger support etc.)

Manu has pointed to some issue behind the obvious issue that will come up again and again unless it's settled once and for all.

Let's call it "To please everyone somewhat (and never really enough) - vs - to stick to a clear and well founded concept".

My personal view is that we should make D a mixed pickles with lots of "but C++ has that" and then some more gadgets thrown in for good measure.

The point that triggered me was "quick and dirty throw away code". Frankly, I don't care batshit about that. Don't get me wrong, Manus desire is doubtlessly valid and I wish him the best of luck to achieve maximum happyness. But I also see that comfort for "throw away code" has a strong tendency to run counter reliability.

There's a gazillion C++ compilers, pretty printers, analysers and other tools out there. And C++ has proven to be useful as a throw away code language - just look at mountains of throw away code out there (they won't call it that, of course).
And there is C#, $Basic, Perl (a perfect language to create trobletickets - or to not even care to), etc, etc.

The issue is not to please crowd A or crowd B. The issue is to make up ones mind and to establish a clear definition of what D is meant to be - and than to bloody stick to it.

D had "reliability" and "safety" written in quite big letters in it's PR. It's a *major* reason for (sure enough not only) me to be here. Comfort and some luxury is important, too, when you make your living using a tool, sure. But that's no contradiction. One can have both.

If I wanted to play a mixture of hide and seek and lottery I'd use C++ in the first place (and would have tools thrown at me).

In case I missed it, could someone kindly point me to a more or less binding priorities list of what D is meant to be and in what order of priorities. Maybe it's my fault and I just didn't see that list. But in case #1 on the list was "to please everyone and then glue some more gadgets to it" I wouldn't be here.

Thanks -R

Correction (3rd paragraph)

My personal view is that we should *not* make D a mixed pickles with
lots of "but C++ has that" and then some more gadgets thrown in
for good measure.

Sorry -R

On Monday, 9 September 2013 at 04:00:39 UTC, Manu wrote:
> On 9 September 2013 05:46, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:
>
>> On 9/8/13, Jesse Phillips <Jesse.K.Phillips+D@gmail.com> wrote:
>> > I realize that we want to make it as painless as possible for
>> > Remedy to switch from C++ to D (along with the rest of the game
>> > developers).
>>
>> FWIW I don't think this has anything to do with Remedy (afaik Manu
>> doesn't work there anymore).
>>
>
> Indeed. These opinions are my own, and I raised it on the merit of our
> experience last weekend in a 48hour game-dev-jam with a few former
> colleagues (including one who still works at Remedy).
> This discussion has come up at remedy in the past, but I don't think this
> is of particular significance to the remedy workflow; the modules were
> small enough to not cause issues, at least not as I left it.
>
> I believe the scenarios I describe are going to be very typical though, at
> least in the game-dev context, particularly when larger volumes of D code
> emerge. I've demonstrated this across 2 separate 48 hour game-jam's now,
> which simulate the environment of a commercial crunch period quite
> faithfully.

Game developers embracing Erlang, C#, Java and ActionScript don't seem to have issues with that, as far as I can tell.

On Monday, 9 September 2013 at 04:00:39 UTC, Manu wrote:
>
> Indeed. These opinions are my own, and I raised it on the merit of our
> experience last weekend in a 48hour game-dev-jam with a few former
> colleagues (including one who still works at Remedy).
> This discussion has come up at remedy in the past, but I don't think this
> is of particular significance to the remedy workflow; the modules were
> small enough to not cause issues, at least not as I left it.
>
> I believe the scenarios I describe are going to be very typical though, at
> least in the game-dev context, particularly when larger volumes of D code
> emerge. I've demonstrated this across 2 separate 48 hour game-jam's now,
> which simulate the environment of a commercial crunch period quite
> faithfully.

I don't believe that typical. We are working with some very big modules, and we have _no_ problems at all regarding that aspect.

I think that this is a swift for the discussion: discussing about an issue that it is present _today_ in a commercial user of the product, or a discussion about an a _potential_ problem.

The worst part of all this mess it is that the proposal ditches one of the *strong* selling point of D: no code duplication, use documentation if you want an overview.

I also strongly disagree that this way of coding is not typical: here at work we are using it without problems with D, and, again, DDocs are the right way.

I would also add that also here we have a lot of time pressures for the releases... as in every commercial software company I know of... ;-P

- Paolo Invernizzi

On 2013-09-09 05:46, Manu wrote:
> Missed the action...
>
> Well it's clear this is not a popular proposal.
> And even to me personally, it's certainly not of critical importance. If
> there was a single thing I'd like to see *DONE* in D, it would be
> temporary/r-value->ref args, without question (really, really annoying
> to work around).

So what's wrong with this approach, that's already working today:

class Foo
{
    void foo ();

    void foo ()
    {

    }
}

void main ()
{
    auto foo = new Foo;
    foo.foo();
}

BTW, this feature was implemented because you asked for it.

-- 
/Jacob Carlborg

On 2013-09-07 19:00, Walter Bright wrote:
> Outlining of member functions is the practice of placing the declaration
> of a member function in the struct/class/union, and placing the
> definition of it at global scope in the module or even in another module.
>
> http://wiki.dlang.org/DIP47

What's wrong with the code below, that works today:

class Foo
{
    void foo ();

    void foo ()
    {
        writeln("Foo.foo");
    }
}

void main ()
{
    auto foo = new Foo;
    foo.foo();
}

-- 
/Jacob Carlborg

On Monday, 9 September 2013 at 07:00:23 UTC, Jacob Carlborg wrote:
> On 2013-09-09 05:46, Manu wrote:
>> Missed the action...
>>
>> Well it's clear this is not a popular proposal.
>> And even to me personally, it's certainly not of critical importance. If
>> there was a single thing I'd like to see *DONE* in D, it would be
>> temporary/r-value->ref args, without question (really, really annoying
>> to work around).
>
> So what's wrong with this approach, that's already working today:
>
> class Foo
> {
>     void foo ();
>
>     void foo ()
>     {
>
>     }
> }
>
> void main ()
> {
>     auto foo = new Foo;
>     foo.foo();
> }
>
> BTW, this feature was implemented because you asked for it.

This is super useful to generate boilerplate from compile time reflection !