On Tuesday, 26 February 2013 at 16:34:01 UTC, renoX wrote:
> On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh wrote:
>> I am a novice D programmer and use C++ in my work. One thing I
>> find myself doing when I need to implement some non-trivial
>> algorithm is that I will originally code it in D and perform
>> testing from there to make sure I have the logic right.
>> Once I have everything working in D I simply port it over to C++.
>
> I'm curious: is this process still useful with C++11?
>
> BR,
> renoX

Have you tried it?

C++11 can prototype faster than C++, but it ain't D.

On Tuesday, 26 February 2013 at 16:55:50 UTC, Craig Dillabaugh wrote:
> On Tuesday, 26 February 2013 at 16:34:01 UTC, renoX wrote:
>> On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh wrote:
>>> I am a novice D programmer and use C++ in my work. One thing I
>>> find myself doing when I need to implement some non-trivial
>>> algorithm is that I will originally code it in D and perform
>>> testing from there to make sure I have the logic right.
>>> Once I have everything working in D I simply port it over to C++.
>>
>> I'm curious: is this process still useful with C++11?
>>
>> BR,
>> renoX
>
> Again since my work is heavily array based probably, I would
> guess so, but perhaps not quite so much.  How long though until
> C++11 is broadly available?

AFAIK, it's already mostly available from both GCC and VS. *Some* functionality is still missing, but nothing major.

On 02/26/2013 04:26 PM, Craig Dillabaugh wrote:
> I am a novice D programmer and use C++ in my work. One thing I
> find myself doing when I need to implement some non-trivial
> algorithm is that I will originally code it in D and perform
> testing from there to make sure I have the logic right.
> Once I have everything working in D I simply port it over to C++.

I have to say that these days (also as someone who programs for scientific research purposes) I find that I can both write _and_ use D effectively -- the range of functionality that I need to rely on is pretty solid in D.  Depending on exactly what it is you need to use, your sense of the "maturity" of D may be paranoid (but of course I appreciate paranoia as a virtue where scientific software is concerned:-).

Now, that said, I can see myself doing exactly what you describe in a case where I really felt the need to use C/C++.  The major reason to do so would probably be ease of access to C or C++ libraries, or collaborative requirements (most of my colleagues are C++ users for serious number crunching, although at least one typically uses FORTRAN).

On 2/26/13 11:46 AM, MattCodr wrote:
> On Tuesday, 26 February 2013 at 15:26:17 UTC, Craig Dillabaugh
> wrote:
>> I was curious to know if anyone else uses D like this.
>
> I usually do this, but in a little different way. I wrote my code
> in a interpreted language, and then I port to D or C languages.

These are great data points. We should figure how to improve D to lessen the barriers in both directions.

Andrei

Andrei Alexandrescu:

> We should figure how to improve D to lessen the barriers in both directions.

Regarding the D => C conversions I write, time ago I have suggested a "-cstyle" compiler switch:

http://d.puremagic.com/issues/show_bug.cgi?id=4580

Bye,
bearophile

On 2013-02-26 18:45, Andrei Alexandrescu wrote:

> These are great data points. We should figure how to improve D to lessen
> the barriers in both directions.

It helps by having convenient functions in the standard library. It also helps with not having to import a lot of modules just to get something simple done.

I don't know if it's that I'm not so used to Phobos but it doesn't feel as intuitive to work with in comparison with say Ruby. In particular with Rails which adds a lot of convenient functions.

-- 
/Jacob Carlborg

On Tue, Feb 26, 2013 at 08:49:12PM +0100, Jacob Carlborg wrote:
> On 2013-02-26 18:45, Andrei Alexandrescu wrote:
> 
> >These are great data points. We should figure how to improve D to lessen the barriers in both directions.
> 
> It helps by having convenient functions in the standard library. It also helps with not having to import a lot of modules just to get something simple done.
> 
> I don't know if it's that I'm not so used to Phobos but it doesn't feel as intuitive to work with in comparison with say Ruby. In particular with Rails which adds a lot of convenient functions.
[...]

Do you have any specific examples?


T

-- 
Study gravitation, it's a field with a lot of potential.

On 2013-02-26 20:52, H. S. Teoh wrote:

> Do you have any specific examples?

Return the date from two days ago:

Ruby on Rails:
2.days.ago
Date.today
Time.now

D:
Clock.currTime - 2.days
// Not sure how to do the other two in D

This is not that bad but it's a bit less intuitive. Here we also have shortening of "current" which just saves three characters, for no reason.

I think it's mostly std.algorithm that is the problem.

* reduce - The "reduce" function is really weird. It can't be used as a property. The signature is:

reduce!(fun)(seed, range)

When it should be:

reduce!(seed, fun)(range)

And:

reduce!(fun)(range, seed)

* No algorithm functions for associative arrays.

* tap - Ruby has a really nice function, "tap". In D it would look like:

T (func, T) (T t)
{
    func(t);
    return t;
}

You can do things like:

Foo foo ()
{
    return (new Foo).tap!((f) {
        f.x = 3;
	f.y = 3;
    });
}

This becomes a bit tricky because we want structs to be passed by ref, but preferably we don't want to be able to change the parameter in the delegate. In Ruby it's no problem since all types are reference types.

I probably can come up with more later.

-- 
/Jacob Carlborg

On 2013-02-26 20:52, H. S. Teoh wrote:

> Do you have any specific examples?

Some more:

isBlank and the opposite isPresent. These exists in Ruby on Rails, this is my D version:

https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/core.d

-- 
/Jacob Carlborg

On 2/26/13 6:01 PM, Jacob Carlborg wrote:
> On 2013-02-26 20:52, H. S. Teoh wrote:
>
>> Do you have any specific examples?
>
> Return the date from two days ago:
>
> Ruby on Rails:
> 2.days.ago
> Date.today
> Time.now
>
> D:
> Clock.currTime - 2.days
> // Not sure how to do the other two in D
>
> This is not that bad but it's a bit less intuitive. Here we also have
> shortening of "current" which just saves three characters, for no reason.
>
> I think it's mostly std.algorithm that is the problem.

And also having to import std.algorithm. In Ruby you can do map, sort and whatever without using an import. You use it so often that an import is annoying.

On Tuesday, 26 February 2013 at 21:10:30 UTC, Ary Borenszweig wrote:
> On 2/26/13 6:01 PM, Jacob Carlborg wrote:
>> On 2013-02-26 20:52, H. S. Teoh wrote:
>>
>>> Do you have any specific examples?
>>
>> Return the date from two days ago:
>>
>> Ruby on Rails:
>> 2.days.ago
>> Date.today
>> Time.now
>>
>> D:
>> Clock.currTime - 2.days
>> // Not sure how to do the other two in D
>>
>> This is not that bad but it's a bit less intuitive. Here we also have
>> shortening of "current" which just saves three characters, for no reason.
>>
>> I think it's mostly std.algorithm that is the problem.
>
> And also having to import std.algorithm. In Ruby you can do map, sort and whatever without using an import. You use it so often that an import is annoying.

I often find myself importing std.algorithm, std.array and std.range even for the simplest things. std.string, std.ascii, std.conv, std.stdio is also quite common at the top of my files.. And *then* I import modules more specific for the problem I'm going to solve :) I sometimes wish I was using an editor that automatically added the imports for me.