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.

Reply via email to