Pitching an investment bank on using D for their bond analytics

[Andy Smith via Digitalmars-d]

   I've spent a few years in the trenches so here are a few 
additional
points that come to mind.. (+1 for John and Rikki's points BTW).

-------------------------------------------------------------------

> - what are the things to emphasise 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.

Extremely fast compiler makes for a very 'fluid' work-flow.

The RDMD compiler wrapper turns D into very effective scripting 
tool

Phobos standard library (subjectively) more useful for finance 
than Boost +
C++

Painless C interop offers many integration possibilities

Syntax is familiar curly brackets so will be familiar to 
C++/Java/.Net devs.

Built-in slice syntax for arrays increasingly important, given 
that
the array of contiguous memory is the new 'go-to' structure for
cache-friendly algorithms.

Paraphrasing Walter + Andrei's collective bios into 28 words or 
less
can impress on management the credibility/gravitas of the 
language.

> - what are the likely pitfalls in the early days?

   Productivity will initially dip while everyone learns D, adapts 
to
new tools etc., but will soon rebound to a higher level - so have
expectations + timescales firmly in place + account for the 
initial
'dip' when making promises.

   Providing adequate tooling for a D-based group in an IB 
environment
may be challenging - Linux distros can be antiquated/bad, unlikely
you'll run as privileged user so a lot hinges on finding helpful
sysadmin(s), desktop OS may be locked down.

   Entrenched IB C++ developers can be difficult to work with. They
tend to cover a spectrum of personality types and abilities. Many 
are
reluctant to change + are not particularly incentivized to embark 
on
'risky' projects. Many are simply intellectually incapable of 
learning
a new language quickly. Best to find out quickly which variety 
you're
dealing with + if they really buy into the idea. They can become 
the
bane of your life if they don't.

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

   Any issues that occur will (fairly or not) tend to be blamed on
having chosen a 'nonstandard' language, so there's an extra risk
associated. But if things go well you can look like a innovator 
:-)

   Integrating with the IB's existing systems may be tricky. If 
you go
'off-piste' (so to speak), the onus will generally be on yourself 
to
get things working; internal service/library providers may push
back against supporting an unconventional language. When 
debugging a
problem you may find yourself obliged to produce a minimal 
example in
a 'supported' language in order to be taken seriously :-(

   Other than that I can't think of any pure technical reason why D
wouldn't be suitable :-)

-------------------------------------------------------------------

   These are first few initial thoughts based on what you've said,
think there's not much detail can be supplied without knowing a 
bit
more about the specifics of what you'll be looking to do. HTH + 
Good
luck!

Cheers,

A.