On 2/26/13 4: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

The last two return the time right now, how come?

Andrei

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++.
>
> In my experience this porting is very trivial (it probably helps
> there that I write D like a C++ programmer). While I don't have
> hard evidence I think that the 'porting' effort to C++ is more
> than offset by the productivity gains I achieve fighting with C++
> syntax while trying to get the logic right. Most of the porting
> effort is simply copying and pasting the D code into my C++
> source files and adding headers, replacing imports with includes,
> etc. Usually significant portions of the code compile without any
> changes.
>
> I was curious to know if anyone else uses D like this. If so this
> might be a good way to try and get D into some C++ shops.  The
> nice thing about D in my opinion is that even for people without
> D experience, if they have C++ experience they can likely 'read'
> D code without much trouble (of course some features might not
> map over so well - but the languages are syntactically very
> close).

I can understand why you are doing this. C++ code tends to be about 3x the volume of well written D code, so a lot of effort is wasted when coding in C++, so if you can get it right through using D, then translate to C++, you'll save a lot of time, but of course we're better off using D directly, but first the language and tool set has to be made production use ready.

Once full shared library support comes about, we'll be able to integrate D libs directly into existing C/C++ code. This allows for a safe migration path away from legacy C/C++ to D.

--rt

On 2013-02-26 22:10, Ary Borenszweig wrote:

> 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.

Often you need std.range and std.array as well.

-- 
/Jacob Carlborg

On 2013-02-27 00:39, Andrei Alexandrescu wrote:

> The last two return the time right now, how come?

They're supposed to. I just accidentally put them below "Return the date from two days ago".

-- 
/Jacob Carlborg

On 26.02.2013 18:45, Andrei Alexandrescu wrote:
> 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

REPL?

On Tuesday, 26 February 2013 at 23:46:52 UTC, Rob T wrote:
> Once full shared library support comes about, we'll be able to integrate D libs directly into existing C/C++ code. This allows for a safe migration path away from legacy C/C++ to D.
>
> --rt

Funny story, I'm doing it the other way around.

I got my program fully working in D, and am porting it to C.

The basic idea is that I'm going to port it "chunk by chunk" to C, while keeping my main in D. This allows me to "package" the finished parts in C, but still work on the rest in D. It also means the porting doesn't have to be done in its totality in a single pass.

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 surprised to see many people doing this. But I'm wondering..
If you already got the code working in D, why not let it stay there and write a C interface?
Company policy? Missing dynamic loading? Some build issues?

If the code could stay in D, it would seem like a good way to slowly integrate D into a company.

On 2/27/13 3:29 AM, Paulo Pinto wrote:
> On 26.02.2013 18:45, Andrei Alexandrescu wrote:
>> 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
>
> REPL?

Good idea. Should be in bugzilla as an enh, although it'll take a while to get to that.

Andrei

> I'm surprised to see many people doing this. But I'm wondering..
> If you already got the code working in D, why not let it stay there and write a C interface?
> Company policy? Missing dynamic loading? Some build issues?
>
> If the code could stay in D, it would seem like a good way to slowly integrate D into a company.

As we said: D isn't mature enough.
As long as your code base isn't too complex, D is very nice but at some point you get many stumbling blocks, bugs or missing features which is very annoying. I like D, but it is far away from using it instead of C++.

On Wednesday, 27 February 2013 at 10:07:43 UTC, Andrei Alexandrescu wrote:
> On 2/27/13 3:29 AM, Paulo Pinto wrote:
>> On 26.02.2013 18:45, Andrei Alexandrescu wrote:
>>> 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
>>
>> REPL?
>
> Good idea. Should be in bugzilla as an enh, although it'll take a while to get to that.
>
> Andrei

D would be one step closer to actually passing the "BOTCH" test!

http://mathprogrammer.com/blog/?p=12