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.
