www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pitching an investment bank on using D for their bond analytics

reply "D Denizen since a year" <nospam gmail.com> writes:
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.
Apr 14 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Apr 14 2015
next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Apr 14 2015
parent reply "D Denizen since a year" <nospam gmail.com> writes:
 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)?
Apr 14 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Apr 14 2015
prev sibling next sibling parent reply "bachmeier" <no spam.net> writes:
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++.
Apr 14 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Apr 14 2015
prev sibling parent reply "D Denizen since a year" <nospam gmail.com> writes:
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.
Apr 14 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Apr 14 2015
parent reply "D Denizen since a year" <nospam gmail.com> writes:
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.
Apr 14 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Apr 14 2015
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Apr 14 2015
parent "D Denizen since a year" <nospam gmail.com> writes:
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.
Apr 14 2015
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Apr 14 2015
parent "D Denizen since a year" <nospam gmail.com> writes:
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).
Apr 14 2015
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
 - 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
Apr 14 2015
parent "D Denizen since a year" <nospam gmail.com> writes:
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).
Apr 14 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Apr 14 2015
prev sibling next sibling parent Justin Whear <justin economicmodeling.com> writes:
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
Apr 14 2015
prev sibling next sibling parent "Andy Smith" <andyrsmith googlemail.com> writes:
   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.
Apr 15 2015
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Tuesday, 14 April 2015 at 12:08:54 UTC, D Denizen since a year 
wrote:

 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.


One of the biggest issues I can think of would be code breakage. 
While we're the point where most compiler updates no longer break 
my code, if you expect to use a codebase from 2 years ago without 
having to update your code, you'll be disappointed.
Apr 15 2015
next sibling parent "lobo" <swamplobo gmail.com> writes:
On Wednesday, 15 April 2015 at 22:32:53 UTC, Kapps wrote:

 On Tuesday, 14 April 2015 at 12:08:54 UTC, D Denizen since a 
 year wrote:

 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.


 One of the biggest issues I can think of would be code 
 breakage. While we're the point where most compiler updates no 
 longer break my code, if you expect to use a codebase from 2 
 years ago without having to update your code, you'll be 
 disappointed.


In the last 2 years each breaking change I've encountered has 
been to close holes where latent bugs may lurk ... and often were 
lurking!

I welcome these breaking changes in production code.

bye,
lobo
Apr 15 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 15 Apr 2015 22:32:52 +0000, Kapps wrote:


 On Tuesday, 14 April 2015 at 12:08:54 UTC, D Denizen since a year wrote:

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


=20
 One of the biggest issues I can think of would be code breakage. While
 we're the point where most compiler updates no longer break my code, if
 you expect to use a codebase from 2 years ago without having to update
 your code, you'll be disappointed.


not that anything is forcing someone to update the working compiler. i=20
know some big codebases that still using msvc6 for the exact reason that=20
"knowing bug is better than new bug".=
Apr 15 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-04-16 00:32, Kapps wrote:


 One of the biggest issues I can think of would be code breakage. While
 we're the point where most compiler updates no longer break my code, if
 you expect to use a codebase from 2 years ago without having to update
 your code, you'll be disappointed.


I don't agree. Every single release since at least DMD 2.050 has broken DWT.

-- 
/Jacob Carlborg
Apr 15 2015