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

You would have to asess if the analysis you should create is time critical. If it is, a possible pitfall is the GC, and you should try to avoid it from the start. Replacing the GC with custom memory management is a lot of work if you do it afterwards. If the analysis is not time critical, I don't see any problems with D.

Kind Regards
Benjamin Thaut

On 15/04/2015 2:17 a.m., D Denizen since a year wrote:
> 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.

That too, but I was thinking more along the lines of writing some business logic. It is very possible outside of a cli app or even web that they would want to use c++ for the user interfacing.
The very worse case scenario here is that they get to learn a new language + possibly write the business logic faster then normal.

After all, business logic probably isn't already designed as pseudo code.

John Colvin:

> A couple of big pluses:
>
> 1) Ease of changing code. D codebases tend to feel more flexible than C++

Thank you - and yes, I agree.
>
> 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.

My guess is these guys aren't going to be writing much assembler, but everyone cares about performance at some point.

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

I will find out more soon, but I doubt it's old IBM mainframes (would guess linux, especially since it's largely a new project).

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

Yes - I think the support/hiring question will be something of a factor.  Let's see.

On Tuesday, 14 April 2015 at 14:21:26 UTC, Rikki Cattermole wrote:

> That too, but I was thinking more along the lines of writing some business logic. It is very possible outside of a cli app or even web that they would want to use c++ for the user interfacing.
> The very worse case scenario here is that they get to learn a new language + possibly write the business logic faster then normal.
>
> After all, business logic probably isn't already designed as pseudo code.

Yes - the business logic is where I come in, so it makes sense from that perspective, too.

On Tuesday, 14 April 2015 at 14:21:15 UTC, Benjamin Thaut wrote:
>
>> - 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.
>>
>
> You would have to asess if the analysis you should create is time critical. If it is, a possible pitfall is the GC, and you should try to avoid it from the start. Replacing the GC with custom memory management is a lot of work if you do it afterwards. If the analysis is not time critical, I don't see any problems with D.
>
> Kind Regards
> Benjamin Thaut

My guess is it's not a major factor, but maybe can design from beginning possibility to use custom allocators.  Ie the part where latency matters does not deal with monster data sizes, and if there is a part where data sizes are large then probably latency will be less critical.  (Outside of HFT, big for this area is much smaller than what other people mean by big).

On 15/04/2015 2:24 a.m., D Denizen since a year wrote:
> On Tuesday, 14 April 2015 at 14:21:26 UTC, Rikki Cattermole wrote:
>
>> That too, but I was thinking more along the lines of writing some
>> business logic. It is very possible outside of a cli app or even web
>> that they would want to use c++ for the user interfacing.
>> The very worse case scenario here is that they get to learn a new
>> language + possibly write the business logic faster then normal.
>>
>> After all, business logic probably isn't already designed as pseudo code.
>
> Yes - the business logic is where I come in, so it makes sense from that
> perspective, too.

I'm available for hire if you need a developer/consultant btw.

On Tuesday, 14 April 2015 at 12:08:54 UTC, D Denizen since a year wrote:
> - 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.

From the business / management PoV I think it is important to emphasize low risk of D investment because of its relation with C/C++. This applies both to the fact that D code has strong interoperating capabilities with C/C++ (so any prototype effort won't be completely lost if discarded) and to the hiring process - it is possible to hire C/C++/Java developers and quickly get them into D development with a quick crash course because there are so many familiar things.

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

Because total community / user base size is well below the critical mass anyone planning to use D in production needs to be read to invest into libraries / tools for domains that no one has been using before. I'd strongly suggest to do preliminary analysis of necessary dependencies and do estimates of what it will take to get it to desired in-house quality.

It is very likely that overall productivity gain will outweight this drawback but it still needs to be taken into schedule.

On Tue, 14 Apr 2015 12:08:53 +0000, D Denizen since a year wrote:

I lead a group that uses D pretty much 100% for a number of different kinds of projects, so I've seen many sides to D's advantages.  That said, I don't enough about investment banking analytics to know exactly what they value.  Here are some suggestions:

What are the sine qua nons of the project?
 * Are there hard performance requirements?
 * Are there specific hardware requirements?
 * Are there software/library requirements (e.g. you must use our
proprietary ...)

These are areas where you must prove that D is adequate, but not necessarily where you should focus.


What characterizes 80% of the code?
 * Large linear algebra problems?
 * High-level business logic that needs to be maintained by an analyst?
 * Database operations?

As an example, if the high-level business logic is the bulk of the codebase, demonstrate how D's cleaner syntax lowers the bar for code review by analysts.  Show how UFCS and pipeline programming allow intuitive and highly-legible composition.  Find some key pain points that D is particularly amenable to solving.  If you can list a few of these sorts of points I might have more concrete suggestions.

Cheers
Justin

On 14 April 2015 at 16:21, D Denizen since a year via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> 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)?

My usual alias (Initial, Surname) at gdcproject.org  - email is also
listed on the site (it may take some looking).

Regards
Iain.

  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.