Hi.

I have been here a year or so, and trust you will forgive my posting pseudonymously on this occasion.  If you guess who it is, please be kind enough not to say for now.

A friend has been invited to be a consultant for an investment bank that would like to build a set of analytics for fixed income products.  The team is currently quite small - about 5 C++ developers - and the idea is to start with a proof of concept and then build on it as there is further buy-in from the business.

Having been using D for a year or so, I am pretty comfortable that it can do the job, and likely much better than the C++ route for all the normal reasons.  I haven't experience of using D in a proper enterprise environment, but I think this group might be open to trying D and that I might be at least part-time involved.

I also have little experience in getting across the merits of this technology to people very used to C++, and so I have not yet built up a standard set of answers to the normal objections to 'buying' that will crop up in any situation of this sort.

So I am interested in:

- what are the things to emphasize in building the case for trying D?  the most effective factors that persuade people are not identical with the technically strongest reasons, because often one needs to see it before one gets it.

- what are the likely pitfalls in the early days?

- what are potential factors that might make D a bad choice in this scenario?  I would like to use D certainly - but it is of course much more important that the client gets the best result, however it is done.

- am I right in thinking C++ integration more or less works, except instantiating C++ templates from D?  what are the gotchas?

(I appreciate there is not so much to go on, and much depends on specific factors).  But any quick thoughts and experiences would be very welcome.

On 15/04/2015 12:08 a.m., D Denizen since a year wrote:
> Hi.
>
> I have been here a year or so, and trust you will forgive my posting
> pseudonymously on this occasion.  If you guess who it is, please be kind
> enough not to say for now.
>
> A friend has been invited to be a consultant for an investment bank that
> would like to build a set of analytics for fixed income products.  The
> team is currently quite small - about 5 C++ developers - and the idea is
> to start with a proof of concept and then build on it as there is
> further buy-in from the business.
>
> Having been using D for a year or so, I am pretty comfortable that it
> can do the job, and likely much better than the C++ route for all the
> normal reasons.  I haven't experience of using D in a proper enterprise
> environment, but I think this group might be open to trying D and that I
> might be at least part-time involved.
>
> I also have little experience in getting across the merits of this
> technology to people very used to C++, and so I have not yet built up a
> standard set of answers to the normal objections to 'buying' that will
> crop up in any situation of this sort.
>
> So I am interested in:
>
> - what are the things to emphasize in building the case for trying D?
> the most effective factors that persuade people are not identical with
> the technically strongest reasons, because often one needs to see it
> before one gets it.
>
> - what are the likely pitfalls in the early days?
>
> - what are potential factors that might make D a bad choice in this
> scenario?  I would like to use D certainly - but it is of course much
> more important that the client gets the best result, however it is done.
>
> - am I right in thinking C++ integration more or less works, except
> instantiating C++ templates from D?  what are the gotchas?
>
> (I appreciate there is not so much to go on, and much depends on
> specific factors).  But any quick thoughts and experiences would be very
> welcome.

Just a thought, try getting them to use D for prototyping. Worse case they will play around with D before settling on e.g. c++. Best case scenario they'll move it into production.

On 14 April 2015 at 14:16, Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 15/04/2015 12:08 a.m., D Denizen since a year wrote:
>>
>> Hi.
>>
>> I have been here a year or so, and trust you will forgive my posting pseudonymously on this occasion.  If you guess who it is, please be kind enough not to say for now.
>>
>> A friend has been invited to be a consultant for an investment bank that would like to build a set of analytics for fixed income products.  The team is currently quite small - about 5 C++ developers - and the idea is to start with a proof of concept and then build on it as there is further buy-in from the business.
>>
>> Having been using D for a year or so, I am pretty comfortable that it can do the job, and likely much better than the C++ route for all the normal reasons.  I haven't experience of using D in a proper enterprise environment, but I think this group might be open to trying D and that I might be at least part-time involved.
>>
>> I also have little experience in getting across the merits of this technology to people very used to C++, and so I have not yet built up a standard set of answers to the normal objections to 'buying' that will crop up in any situation of this sort.
>>
>> So I am interested in:
>>
>> - what are the things to emphasize in building the case for trying D? the most effective factors that persuade people are not identical with the technically strongest reasons, because often one needs to see it before one gets it.
>>
>> - what are the likely pitfalls in the early days?
>>
>> - what are potential factors that might make D a bad choice in this scenario?  I would like to use D certainly - but it is of course much more important that the client gets the best result, however it is done.
>>
>> - am I right in thinking C++ integration more or less works, except instantiating C++ templates from D?  what are the gotchas?
>>
>> (I appreciate there is not so much to go on, and much depends on specific factors).  But any quick thoughts and experiences would be very welcome.
>
>
> Just a thought, try getting them to use D for prototyping. Worse case they will play around with D before settling on e.g. c++. Best case scenario they'll move it into production.

The best case scenario has happened at least once before in a similarly-based company.

On Tuesday, 14 April 2015 at 12:08:54 UTC, D Denizen since a year wrote:
> Hi.
>
> I have been here a year or so, and trust you will forgive my posting pseudonymously on this occasion.  If you guess who it is, please be kind enough not to say for now.
>
> A friend has been invited to be a consultant for an investment bank that would like to build a set of analytics for fixed income products.  The team is currently quite small - about 5 C++ developers - and the idea is to start with a proof of concept and then build on it as there is further buy-in from the business.
>
> Having been using D for a year or so, I am pretty comfortable that it can do the job, and likely much better than the C++ route for all the normal reasons.  I haven't experience of using D in a proper enterprise environment, but I think this group might be open to trying D and that I might be at least part-time involved.
>
> I also have little experience in getting across the merits of this technology to people very used to C++, and so I have not yet built up a standard set of answers to the normal objections to 'buying' that will crop up in any situation of this sort.
>
> So I am interested in:
>
> - what are the things to emphasize in building the case for trying D?  the most effective factors that persuade people are not identical with the technically strongest reasons, because often one needs to see it before one gets it.
>
> - what are the likely pitfalls in the early days?
>
> - what are potential factors that might make D a bad choice in this scenario?  I would like to use D certainly - but it is of course much more important that the client gets the best result, however it is done.
>
> - am I right in thinking C++ integration more or less works, except instantiating C++ templates from D?  what are the gotchas?
>
> (I appreciate there is not so much to go on, and much depends on specific factors).  But any quick thoughts and experiences would be very welcome.

A couple of big pluses:

1) Ease of changing code. D codebases tend to feel more flexible than C++

2) Easy to transparently make use of highly optimised low-level code in high level constructs, whether that means carefully written D, inline asm or calling out to established C(++) libraries.

Possible pitfalls:

1) What systems are being targeted? D on obscure big-iron is a very different prospect to D on a bunch of x86 linux servers.

2) Added maintenance due to language/library changes, however minor. Not a particularly big deal IMO, particularly when your writing a piece of software for in-house usage.

3) Limited support options. There aren't swathes of consultants available at any time to fix your urgent problems.

"D Denizen since a year"  wrote in message news:qpharcskwrbfgkuubfrw@forum.dlang.org...

> - am I right in thinking C++ integration more or less works, except instantiating C++ templates from D?  what are the gotchas?

C++ integration can be made to work, as in data can be passed back and forth and most function calls will work.  The gotchas are everywhere, and getting non-trivial C++ interop working is a fairly advanced task that will require changes on both the C++ and D side.  Heavily templated code is especially difficult. 

On Tuesday, 14 April 2015 at 12:16:40 UTC, Rikki Cattermole wrote:
> On 15/04/2015 12:08 a.m., D Denizen since a year wrote:
>> Hi.
>>
>> I have been here a year or so, and trust you will forgive my posting
>> pseudonymously on this occasion.  If you guess who it is, please be kind
>> enough not to say for now.
>>
>> A friend has been invited to be a consultant for an investment bank that
>> would like to build a set of analytics for fixed income products.  The
>> team is currently quite small - about 5 C++ developers - and the idea is
>> to start with a proof of concept and then build on it as there is
>> further buy-in from the business.
>>
>> Having been using D for a year or so, I am pretty comfortable that it
>> can do the job, and likely much better than the C++ route for all the
>> normal reasons.  I haven't experience of using D in a proper enterprise
>> environment, but I think this group might be open to trying D and that I
>> might be at least part-time involved.
>>
>> I also have little experience in getting across the merits of this
>> technology to people very used to C++, and so I have not yet built up a
>> standard set of answers to the normal objections to 'buying' that will
>> crop up in any situation of this sort.
>>
>> So I am interested in:
>>
>> - what are the things to emphasize in building the case for trying D?
>> the most effective factors that persuade people are not identical with
>> the technically strongest reasons, because often one needs to see it
>> before one gets it.
>>
>> - what are the likely pitfalls in the early days?
>>
>> - what are potential factors that might make D a bad choice in this
>> scenario?  I would like to use D certainly - but it is of course much
>> more important that the client gets the best result, however it is done.
>>
>> - am I right in thinking C++ integration more or less works, except
>> instantiating C++ templates from D?  what are the gotchas?
>>
>> (I appreciate there is not so much to go on, and much depends on
>> specific factors).  But any quick thoughts and experiences would be very
>> welcome.
>
> Just a thought, try getting them to use D for prototyping. Worse case they will play around with D before settling on e.g. c++. Best case scenario they'll move it into production.

Or maybe they can write some smaller pieces in D and call them from C++.

On 15/04/2015 1:44 a.m., bachmeier wrote:
> On Tuesday, 14 April 2015 at 12:16:40 UTC, Rikki Cattermole wrote:
>> On 15/04/2015 12:08 a.m., D Denizen since a year wrote:
>>> Hi.
>>>
>>> I have been here a year or so, and trust you will forgive my posting
>>> pseudonymously on this occasion.  If you guess who it is, please be kind
>>> enough not to say for now.
>>>
>>> A friend has been invited to be a consultant for an investment bank that
>>> would like to build a set of analytics for fixed income products.  The
>>> team is currently quite small - about 5 C++ developers - and the idea is
>>> to start with a proof of concept and then build on it as there is
>>> further buy-in from the business.
>>>
>>> Having been using D for a year or so, I am pretty comfortable that it
>>> can do the job, and likely much better than the C++ route for all the
>>> normal reasons.  I haven't experience of using D in a proper enterprise
>>> environment, but I think this group might be open to trying D and that I
>>> might be at least part-time involved.
>>>
>>> I also have little experience in getting across the merits of this
>>> technology to people very used to C++, and so I have not yet built up a
>>> standard set of answers to the normal objections to 'buying' that will
>>> crop up in any situation of this sort.
>>>
>>> So I am interested in:
>>>
>>> - what are the things to emphasize in building the case for trying D?
>>> the most effective factors that persuade people are not identical with
>>> the technically strongest reasons, because often one needs to see it
>>> before one gets it.
>>>
>>> - what are the likely pitfalls in the early days?
>>>
>>> - what are potential factors that might make D a bad choice in this
>>> scenario?  I would like to use D certainly - but it is of course much
>>> more important that the client gets the best result, however it is done.
>>>
>>> - am I right in thinking C++ integration more or less works, except
>>> instantiating C++ templates from D?  what are the gotchas?
>>>
>>> (I appreciate there is not so much to go on, and much depends on
>>> specific factors).  But any quick thoughts and experiences would be very
>>> welcome.
>>
>> Just a thought, try getting them to use D for prototyping. Worse case
>> they will play around with D before settling on e.g. c++. Best case
>> scenario they'll move it into production.
>
> Or maybe they can write some smaller pieces in D and call them from C++.

Yeah, that would be middle ground.

Rikki:

> Just a thought, try getting them to use D for prototyping. Worse case they will play around with D before settling on e.g. c++. Best case scenario they'll move it into production.

Good point.  Pick a small part of the project (especially something I 'prepared earlier') and get them to feel comfortable first.

On Tuesday, 14 April 2015 at 13:17:09 UTC, Daniel Murphy wrote:
> "D Denizen since a year"  wrote in message news:qpharcskwrbfgkuubfrw@forum.dlang.org...
>
>> - am I right in thinking C++ integration more or less works, except instantiating C++ templates from D?  what are the gotchas?
>
> C++ integration can be made to work, as in data can be passed back and forth and most function calls will work.  The gotchas are everywhere, and getting non-trivial C++ interop working is a fairly advanced task that will require changes on both the C++ and D side.  Heavily templated code is especially difficult.

Is there anything anyone has on the gotchas for non-templated stuff?  I am sure this would be of more general interest, since everybody likely has some legacy code they want to connect with.

I get the impression the subset of C++ people often restrict themselves to tends not to favour heavy metaprogramming, but I don't know how much template stuff they actually tend to do at this place.  (Will find out).

> The best case scenario has happened at least once before in a
> similarly-based company.

Hi Iain.

What's best way to reach you by email for quick follow-up on this (if you would not mind - no hurry)?