www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - good reasons not to use D?

reply Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
I'm writing a talk for codemesh on the use of D in finance.

I want to start by addressing the good reasons not to use D.  (We 
all know what the bad ones are).  I don't want to get into a 
discussion here on them, but just wanted to make sure I cover 
them so I represent the state of affairs correctly.

So far what comes to mind: heavy GUI stuff (so far user interface 
code is not what it could be); cases where you want to write 
quick one-off scripts that need to use a bunch of different 
libraries not yet available in D and where it doesn't make sense 
to wrap or port them; where you have a lot of code in another 
language (especially non C, non Python) and defining an interface 
is not so easy; where you have many inexperienced programmers and 
they need to be productive very quickly.

Any other thoughts?
Oct 30 2015
next sibling parent reply ref2401 <refactor24 gmail.com> writes:
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.

 I want to start by addressing the good reasons not to use D.  
 (We all know what the bad ones are).  I don't want to get into 
 a discussion here on them, but just wanted to make sure I cover 
 them so I represent the state of affairs correctly.

 So far what comes to mind: heavy GUI stuff (so far user 
 interface code is not what it could be); cases where you want 
 to write quick one-off scripts that need to use a bunch of 
 different libraries not yet available in D and where it doesn't 
 make sense to wrap or port them; where you have a lot of code 
 in another language (especially non C, non Python) and defining 
 an interface is not so easy; where you have many inexperienced 
 programmers and they need to be productive very quickly.

 Any other thoughts?


I'd suggest enterprise software because many necessary libraries 
and tools do not exist in D ecosystem. Though you've already 
named these reasons.
Oct 30 2015
parent Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Saturday, 31 October 2015 at 05:25:06 UTC, ref2401 wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.

 I want to start by addressing the good reasons not to use D.  
 (We all know what the bad ones are).  I don't want to get into 
 a discussion here on them, but just wanted to make sure I 
 cover them so I represent the state of affairs correctly.

 So far what comes to mind: heavy GUI stuff (so far user 
 interface code is not what it could be); cases where you want 
 to write quick one-off scripts that need to use a bunch of 
 different libraries not yet available in D and where it 
 doesn't make sense to wrap or port them; where you have a lot 
 of code in another language (especially non C, non Python) and 
 defining an interface is not so easy; where you have many 
 inexperienced programmers and they need to be productive very 
 quickly.

 Any other thoughts?


 I'd suggest enterprise software because many necessary 
 libraries and tools do not exist in D ecosystem. Though you've 
 already named these reasons.


Thank you very much to every one who has replied on this thread, 
and my apologies for not engaging - just haven't had time.  But I 
have read them all and it will help me clarify what I say.

Incidentally, there is enterprise and enterprise.  What's 
necessary really depends on what you're trying to do.  For me, so 
far, I don't see the lack of libraries as a major problem.  How 
much work really is it to port some bindings?  Not much in 
relation to the larger goal.  I've done that myself for many of 
them I wanted so far, because I wanted to get to know the tools I 
was working with and you can't delegate learning.  In coming 
months others will be helping me, which will allow me to spend a 
bit more time and energy on the investment aspect and the bigger 
picture.

That's not only been my perspective, but also that of other 
financial adopters of languages perceived as niche - for example, 
Jane Street with ocaml.

A benefit of the D community that also resonates with what Yaron 
Minsky at Jane Street says about ocaml is that there are some 
very good programmers here (and the less experienced ones learn 
from the more experienced ones, and the reason that's possible is 
the very thing that turns off more corporate sorts of people - 
it's a small community so people have more time and energy to 
spend).  You couldn't buy for any price what people I have talked 
to have learnt by becoming language contributors...


Laeeth.
Nov 02 2015
prev sibling next sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.

 Any other thoughts?


For finance stuff - missing a floating point decimal data type. 
Things like 1.1 + 2.2 = 3.3000000000000003
Oct 31 2015
next sibling parent reply tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.

 Any other thoughts?


 For finance stuff - missing a floating point decimal data type. 
 Things like 1.1 + 2.2 = 3.3000000000000003


I always thought that this type of arithmetic operations can be 
solved with BigInt, but never tried it. Since the issue is 
related to IEEE standard, a simulated (not supported by hardware 
directly) data type might be required.
Oct 31 2015
next sibling parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sat, 2015-10-31 at 15:41 +0000, tcak via Digitalmars-d-learn wrote:

 On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.
=20
 Any other thoughts?


=20
 For finance stuff - missing a floating point decimal data type.=20
 Things like 1.1 + 2.2 =3D 3.3000000000000003


=20
 I always thought that this type of arithmetic operations can be=20
 solved with BigInt, but never tried it. Since the issue is=20
 related to IEEE standard, a simulated (not supported by hardware=20
 directly) data type might be required.


In that std.bigint.BigInt provides the accuracy, yes it does suffice.
But it is slow. As far as I am aware only IBM Big Iron (aka mainframes,
aka z-Series) has hardware decimal floating point these days. (Even
though 1970s and 1980s microprocessors had the feature.)

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 31 2015
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/31/2015 09:06 AM, Russel Winder via Digitalmars-d-learn wrote:


 As far as I am aware only IBM Big Iron (aka mainframes, aka z-Series) has
 hardware decimal floating point these days. (Even though 1970s and 1980s
 microprocessors had the feature.)


Although still years away from production, the Mill CPU will have 
decimal floating point:

   http://millcomputing.com/wiki/Instruction_Set

Ali
Oct 31 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 31 October 2015 at 23:16:04 UTC, Ali Çehreli wrote:

 Although still years away from production, the Mill CPU will 
 have decimal floating point:

   http://millcomputing.com/wiki/Instruction_Set



Mill is a fun project, and there are also base 10 floating point 
FPGA coprocessors available, but probably not widely deployed.

I've personally settled for storing in cents instead, as integers 
have accurate precision (storing "30.0" instead of "0.3"). The 
problem is then reduced to writing a wrapper for floats with a 
dedicated string_to_float conversion that is loss free.
Nov 01 2015
prev sibling parent reply Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Saturday, 31 October 2015 at 16:06:47 UTC, Russel Winder wrote:

 On Sat, 2015-10-31 at 15:41 +0000, tcak via Digitalmars-d-learn 
 wrote:

 On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc 
 wrote:

 I'm writing a talk for codemesh on the use of D in finance.
 
 Any other thoughts?


 
 For finance stuff - missing a floating point decimal data 
 type. Things like 1.1 + 2.2 = 3.3000000000000003


 
 I always thought that this type of arithmetic operations can 
 be solved with BigInt, but never tried it. Since the issue is 
 related to IEEE standard, a simulated (not supported by 
 hardware directly) data type might be required.


 In that std.bigint.BigInt provides the accuracy, yes it does 
 suffice. But it is slow. As far as I am aware only IBM Big Iron 
 (aka mainframes, aka z-Series) has hardware decimal floating 
 point these days. (Even though 1970s and 1980s microprocessors 
 had the feature.)


It would be nice to have fixed point numbers in Phobos, although 
it's not much work to implement, and there is a library solution 
already (which is maintained, but sometimes for a while breaks 
with newer versions of dmd).
Nov 02 2015
parent steven kladitis <steven_kladitis yahoo.com> writes:
On Monday, 2 November 2015 at 17:09:41 UTC, Laeeth Isharc wrote:

 On Saturday, 31 October 2015 at 16:06:47 UTC, Russel Winder 
 wrote:

 On Sat, 2015-10-31 at 15:41 +0000, tcak via 
 Digitalmars-d-learn wrote:

 [...]


 In that std.bigint.BigInt provides the accuracy, yes it does 
 suffice. But it is slow. As far as I am aware only IBM Big 
 Iron (aka mainframes, aka z-Series) has hardware decimal 
 floating point these days. (Even though 1970s and 1980s 
 microprocessors had the feature.)


 It would be nice to have fixed point numbers in Phobos, 
 although it's not much work to implement, and there is a 
 library solution already (which is maintained, but sometimes 
 for a while breaks with newer versions of dmd).


I am Big Proponent of decimal arithmetic. It should be a breeze 
for a some of the smart folks using D. :):)
Nov 03 2015
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Saturday, 31 October 2015 at 15:42:00 UTC, tcak wrote:

 On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc 
 wrote:

 I'm writing a talk for codemesh on the use of D in finance.

 Any other thoughts?


 For finance stuff - missing a floating point decimal data 
 type. Things like 1.1 + 2.2 = 3.3000000000000003


 I always thought that this type of arithmetic operations can be 
 solved with BigInt, but never tried it. Since the issue is 
 related to IEEE standard, a simulated (not supported by 
 hardware directly) data type might be required.


Bigint îs enough only for addition or subtraction as long as you 
keep a commonly agreed constant scale. Once you need 
multiplication, division or rounding, managing a dynamic scale 
can be very messy.

IEEE standard is also divided between two standard formats: DPD 
preferred by IBM and BID preferred by Intel.

Currently a DPD partial implementation is available on 
code.dlang.org; Unfortunately it's not updated since 4 months. 
The author proposed this for phobos integration without success.

My opinion is that a decimal data type must be builtin in any 
modern language, not implemented as a library.
Oct 31 2015
next sibling parent Andrea Fontana <nospam example.com> writes:
On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:

 My opinion is that a decimal data type must be builtin in any 
 modern language, not implemented as a library.


I agree
Oct 31 2015
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:

 My opinion is that a decimal data type must be builtin in any 
 modern language, not implemented as a library.


"must be builtin in any modern language" – which modern languages 
actually have decimals as a built-in type, and what is your 
rationale against having them as a solid library implementation? 
It seems like it would only be interesting for a very fringe 
sector of users (finance, and only the part of it that actually 
deals with accounting).

  — David
Oct 31 2015
next sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Saturday, 31 October 2015 at 20:55:33 UTC, David Nadlinger 
wrote:

 On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:

 My opinion is that a decimal data type must be builtin in any 
 modern language, not implemented as a library.


 "must be builtin in any modern language" – which modern 
 languages actually have decimals as a built-in type, and what 
 is your rationale against having them as a solid library 
 implementation? It seems like it would only be interesting for 
 a very fringe sector of users (finance, and only the part of it 
 that actually deals with accounting).

  — David



bit sign and scale) - 
https://msdn.microsoft.com/en-us/library/364x0z75.aspx
GNU C - 3 built-in decimal data types - 
https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html

Besides that, according to the last IEEE-2008 standard, any 
language must implement decimal floating point support at the 
same level of binary float support. Once al language has float, 
double and real, must also define decimal counterparts - 
decimal32, decimal64 and decimal128.

Concerning the advantages of a built-in data type, it happens to 
work right now to a decimal BID floating point implementation, 
here is a list of problems I encountered during development:

- literals - right now the only way to define literals is a 
templated string, using float literals will result in precision 
loss, since binary floating point cannot be represented exactly.
- correct comparison operators - operator overloading doesn't 
allow unordered comparisons similar to binary data types. 
Comparing any NaN, must always return false, implementing 
opEquals is not enough is this case, since a != b is equivalent 
to !(a == b)
- implicit casting cannot be defined - a decimal32 must be 
implicitly convertible to decimal64 and a decimal64 must be 
implicitly convertible to decimal128.
- using a global DecimalContext (according to IEEE standard) - 
similar to std.math.FloatingPointControl, will make all your 
functions impure. Throwing exceptions according also to IEEE 
standard will make any calculation garbage collected. The 
compiler can override this behaviour as it's doing in the binary 
floating point case, they are also using a global context and 
throw exceptions.
- BigInt is unsuitable as backend for decimal128 data type since 
it allocates on overflow, therefore all your operations will be 
garbage collected. Also BigInt is using uint arrays as backend, 
there is no performance optimisation for 64 bit arithmetic, 
that's why is slow. Adding a scale to the BigInt is not enough, 
once you need to multiply values with high-precision percents, 
you must keep all your numbers scaled to many, many digits 
resulting in very poor performance.
- Efficient 128 bit arithmetic is missing since ucent is not 
implemented and the decimal128 data type is heavily built on it. 
Writing your own 128 bit data type will have the same 
disadvantages as exposed above. As a fun fact, through trial and 
error, I discovered that a FPU division is faster than the 
Newton–Raphson applied to wide integral data types. Probably, a 
fine tuned assembler implementation is faster than that. Since 
there are operations calculated using unlimited precision like 
fma(), there is also need for efficient >128 bit arithmetic.
- Impurity and garbage collection being involved, the CTFE is not 
always available.
- Heavily templating your code to cover all three decimal data 
types, will result in unintelligible compiler errors like "Out of 
memory" and will render features like code completion useless. 
Using mixins will break out syntax highlighting, code completion 
and documentation; to cope with that you will finally copy-paste 
code all over the place.
- you cannot interfere with compiler optimisations, eg comparing 
a decimal value to 0 in certain cases can be done with a simple 
bit test, instead of a fully featured function, even inlined.

Yes, I'm working in the "very fringe sector of users" - financial 
apps. So banks, insurance companies, investment funds and 
accounting firms are a very fringe sector. In most cases they are 
using Java for development, a very fringe language. Good to know 
that.
Oct 31 2015
parent rsw0x <anonymous anonymous.com> writes:
On Saturday, 31 October 2015 at 23:07:46 UTC, rumbu wrote:

 On Saturday, 31 October 2015 at 20:55:33 UTC, David Nadlinger 
 wrote:

 On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:

 My opinion is that a decimal data type must be builtin in any 
 modern language, not implemented as a library.


 "must be builtin in any modern language" – which modern 
 languages actually have decimals as a built-in type, and what 
 is your rationale against having them as a solid library 
 implementation? It seems like it would only be interesting for 
 a very fringe sector of users (finance, and only the part of 
 it that actually deals with accounting).

  — David


 GNU C - 3 built-in decimal data types - 
 https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html


This is a vendor-specific extension and likely exposed by GDC 
already.
Oct 31 2015
prev sibling parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sat, 2015-10-31 at 20:55 +0000, David Nadlinger via Digitalmars-d-
learn wrote:

 On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:

 My opinion is that a decimal data type must be builtin in any=20
 modern language, not implemented as a library.


=20
 "must be builtin in any modern language" =E2=80=93=C2=A0which modern lang=


uages=20

 actually have decimals as a built-in type, and what is your=20
 rationale against having them as a solid library implementation?=20
 It seems like it would only be interesting for a very fringe=20
 sector of users (finance, and only the part of it that actually=20
 deals with accounting).
=20
 =C2=A0 =E2=80=94=C2=A0David


It is really a question of symmetry: if there are hardware
implementations of both binary and denary floating point, then if a
language has binary floating point in the language, then it should have
denary floating point in the language. To support one hardware type in
the language but relegate another hardware type to the library is
inappropriate discrimination.

If I remember correctly (I am on a very poor Internet connection just
now and can't do the necessary research), IBM z-series has two
different denary hardware types, and there is currently a question as
to which of these to draw into the IEEE standard as the preferred type.
I think Intel are muttering about which one to support.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Nov 01 2015
prev sibling next sibling parent rsw0x <anonymous anonymous.com> writes:
On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.

 Any other thoughts?


 For finance stuff - missing a floating point decimal data type. 
 Things like 1.1 + 2.2 = 3.3000000000000003


Isn't D used by a rather large banking company internally? I 
believe I remember this being mentioned somewhere.
Oct 31 2015
prev sibling parent DLearner <bmqazwsx123 gmail.com> writes:
On Saturday, 31 October 2015 at 14:37:23 UTC, rumbu wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.

 Any other thoughts?


 For finance stuff - missing a floating point decimal data type. 
 Things like 1.1 + 2.2 = 3.3000000000000003


Agreed.

Suggest 'dec' type.

Example:
dec foo{15,3};

Means simple variable 'foo' can hold fifteen digits, last three 
decimal places.

DLearner
Nov 03 2015
prev sibling next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 Any other thoughts?


Floating point operations can be extended automatically (without 
some kind of 'fastmath' flag) up to 80bit fp on 32 bit intel 
processors. This is worst solution for language that want to be 
used in accounting or math.

Thoughts like "larger precision entails more accurate answer" are 
naive and wrong.

--Ilya
Nov 01 2015
parent reply Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Sunday, 1 November 2015 at 09:07:56 UTC, Ilya Yaroshenko wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 Any other thoughts?


 Floating point operations can be extended automatically 
 (without some kind of 'fastmath' flag) up to 80bit fp on 32 bit 
 intel processors. This is worst solution for language that want 
 to be used in accounting or math.

 Thoughts like "larger precision entails more accurate answer" 
 are naive and wrong.

 --Ilya


Thanks, Ilya.  An important but subtle point.  Funnily enough, I 
haven't done so much specifically heavily numerical work so far, 
but trust that in the medium term the dlangscience project by 
John Colvin and others will bear fruit.

What would you suggest is a better option to address the concerns 
you raised?
Nov 02 2015
parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Monday, 2 November 2015 at 17:07:33 UTC, Laeeth Isharc wrote:

 On Sunday, 1 November 2015 at 09:07:56 UTC, Ilya Yaroshenko 
 wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc 
 wrote:

 Any other thoughts?


 Floating point operations can be extended automatically 
 (without some kind of 'fastmath' flag) up to 80bit fp on 32 
 bit intel processors. This is worst solution for language that 
 want to be used in accounting or math.

 Thoughts like "larger precision entails more accurate answer" 
 are naive and wrong.

 --Ilya


 Thanks, Ilya.  An important but subtle point.  Funnily enough, 
 I haven't done so much specifically heavily numerical work so 
 far, but trust that in the medium term the dlangscience project 
 by John Colvin and others will bear fruit.

 What would you suggest is a better option to address the 
 concerns you raised?


The main goal is that we need to rewrite std.math & 
std.mathspecial to
1. Support all FP types (float/double)
2. Be portable (no Assembler when possible!, we _can_ use CEPHES 
code)
3. Produce equal results on different machines with different 
compilers for float/double.

The problem is that many math functions use compensatory hacks to 
make result more accurate. But this hack have _very_ bad 
behaviour if we allow 80bit math for double and float.

Q: What we need to change?
A: Only dmd backend for old intel/amd 32 bit processors without 
sse support. Other compilers and platforms are not affected. So, 
D will have the same FP behaviour like C.

See also the comment: 
https://github.com/D-Programming-Language/phobos/pull/2991#issuecomment-74506203

-- Ilya
Nov 05 2015
prev sibling next sibling parent reply Freddy <Hexagonalstar64 gmail.com> writes:
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.

 I want to start by addressing the good reasons not to use D.  
 (We all know what the bad ones are).  I don't want to get into 
 a discussion here on them, but just wanted to make sure I cover 
 them so I represent the state of affairs correctly.

 So far what comes to mind: heavy GUI stuff (so far user 
 interface code is not what it could be); cases where you want 
 to write quick one-off scripts that need to use a bunch of 
 different libraries not yet available in D and where it doesn't 
 make sense to wrap or port them; where you have a lot of code 
 in another language (especially non C, non Python) and defining 
 an interface is not so easy; where you have many inexperienced 
 programmers and they need to be productive very quickly.

 Any other thoughts?


I would advise against using D in applications where memory is 
essential. Idiomatic D uses a garbage collector which has a non 
free runtime cost.
Nov 01 2015
parent Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Sunday, 1 November 2015 at 20:38:44 UTC, Freddy wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.

 I want to start by addressing the good reasons not to use D.  
 (We all know what the bad ones are).  I don't want to get into 
 a discussion here on them, but just wanted to make sure I 
 cover them so I represent the state of affairs correctly.

 So far what comes to mind: heavy GUI stuff (so far user 
 interface code is not what it could be); cases where you want 
 to write quick one-off scripts that need to use a bunch of 
 different libraries not yet available in D and where it 
 doesn't make sense to wrap or port them; where you have a lot 
 of code in another language (especially non C, non Python) and 
 defining an interface is not so easy; where you have many 
 inexperienced programmers and they need to be productive very 
 quickly.

 Any other thoughts?


 I would advise against using D in applications where memory is 
 essential. Idiomatic D uses a garbage collector which has a non 
 free runtime cost.


Idiomatic D doesn't need to use the GC, and may generate much 
less garbage anyway.  Andrei's allocator is pretty easy to use, 
and EMSI containers on top make it even easier.  And those aren't 
the only options.
Nov 02 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

Interesting. Two points suggest that you should use D only for 
serious programming:

"cases where you want to write quick one-off scripts that need to 
use a bunch of different libraries not yet available in D and 
where it doesn't make sense to wrap or port them" - quick and 
dirty

"where you have many inexperienced programmers and they need to 
be productive very quickly." - quick and awkward

[what does this tell us about financial programming ...]

This reason is true of any other language:

"where you have a lot of code in another language (especially non 
C, non Python) and defining an interface is not so easy;"

In fact, the reasons you give (apart from the point about GUI) 

thinking of D specific reasons like lack of support for mobile 
platforms (not 100% yet). So your average stock broker couldn't 
calculate some bogus numbers on his iPad while having a latte and 
a Pelegrino in a posh cafe off Wallstreet. He he he.

GC and lack of mobile are real reasons not to use D.
Nov 03 2015
parent reply Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Tuesday, 3 November 2015 at 23:37:36 UTC, Chris wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 Interesting. Two points suggest that you should use D only for 
 serious programming:

 "cases where you want to write quick one-off scripts that need 
 to use a bunch of different libraries not yet available in D 
 and where it doesn't make sense to wrap or port them" - quick 
 and dirty

 "where you have many inexperienced programmers and they need to 
 be productive very quickly." - quick and awkward

 [what does this tell us about financial programming ...]

 This reason is true of any other language:

 "where you have a lot of code in another language (especially 
 non C, non Python) and defining an interface is not so easy;"

 In fact, the reasons you give (apart from the point about GUI) 

 thinking of D specific reasons like lack of support for mobile 
 platforms (not 100% yet). So your average stock broker couldn't 
 calculate some bogus numbers on his iPad while having a latte 
 and a Pelegrino in a posh cafe off Wallstreet. He he he.

 GC and lack of mobile are real reasons not to use D.



Thanks, Chris, appreciate the feedback.  I gave talk yesterday to 
a select but interested audience.  Slides should be up soon - 
couple typos and as Andrei points out a bit too dense.  (It's 
easy to forget when you read very quickly that not everyone does, 
and I should be more considerate of an audience).  I really would 
have liked to have spent a bit more time preparing, as many 
things came together on other fronts so I had to do the best I 
could with the time available.

You're right that I made it sound like D isn't a language for 
non-serious programming - well not quite, but more in that 
direction - and I should find a way to be clear about this 
anyway.  Fact is I use it for scripts all the time. But if I ask 
myself, would I recommend it to someone who won't also use it for 
serious things, or has to depend on getting a bunch of junior 
guys with little experience (and with a low tolerance for 
discomfort) no I would not.


 [what does this tell us about financial programming ...]


I'm an elitist (albeit a kind, open-hearted one), and I think 
that the research about the differences between productivity 
across almost any domain is right and underappreciated, and that 
it matters because if you don't recognize this then you won't 
organize your business so as to make it possible for these people 
to perform at that level.  It's because of that and because the 
language appeals to me that I am here.

Paper is here:
https://www.evernote.com/shard/s37/sh/12b86414-ed93-472d-9a6f-db223087d869/62f13d679581134ef1d368d5b57cd2b7

Yaron Minsky said that at Jane Street they had the luxury of only 
hiring good programmers (and so the possible difficulty of ocaml 
simply wasn't a factor).  I applaud the sentiment, and agree.

This somewhat american conception of the rockstar programmer 
simply misses the point.  That isn't how these people are, and 
they won't all be paid gazillions of dollars.  One just has to 
have the discernment to recognize talent, earn its respect (which 
can only be if you make yourself worthy of it), provide working 
conditions that are suited to it, and figure out how to address 
the particular challenges of working with creative people.

I don't know about financial programming in general - it's a 
really big sector and requirements are not the same.  Even within 
my narrow little part of it, what I am doing (or at least a good 
part of it) is a bit different from anyone else I know, and the 
organizational approach and its flexibility is certainly so.  I 
wouldn't characterize the difficulty level as high - what it will 
do is quite interesting, but in the stages I'm at for now, it's 
by far not the most technically difficult thing I have worked on. 
  But I have a lot to achieve with somewhat limited resources in 
the beginning, which makes the challenge more interesting.


 This reason is true of any other language:

 "where you have a lot of code in another language (especially 
 non C, non Python) and defining an interface is not so easy;"


True.  But it doesn't matter for Java as you aren't going to be 
limited by libraries and if you're thinking about using Java it's 
something obvious to you.  Whereas if you know nothing about D 
(and nobody in the audience had even downloaded DMD) then it's 
not (and it matters much more for D).  And if you want to speak 
credibly, it's much better to be honest - if you got it, you 
don't need to make it flashy.  I don't see that many talks on 
other emerging languages by proponents talking about the rough 
edges, and maybe that's because it's a bad idea, but maybe it's 
not.  If I were being paid to sell D (a job I would never take if 
I could not speak about the rougher aspects) then it might be 
different - but it was a talk from a practitioner's perspective, 
one who deeply appreciates the language and the community, but 
not a fanatic.

I've been sold to a lot in the years, and I find people who are 
honest with me about the problems are much more convincing.  
Depends on your target market, but the natural D demographic 
isn't going to be easily fooled anyway, so it's one of those nice 
occasions where doing the right thing has no cost.


 In fact, the reasons you give (apart from the point about GUI) 



Really?  I think yes abstractly "cases where you want to write 
quick one-off scripts that need to use a bunch of different 
libraries not yet available in D and where it doesn't make sense 
to wrap or port them" is true of many languages.  But practically 
speaking (and I'm acting for now as a merchant, albeit one with 
an aesthetic, non-mercantile appreciation) this hardly matters 
for Java, C++, Python etc because mostly you won't need to use a 
bunch of different libraries.

Porting and wrapping things has definitely cost me some time, but 
I don't mind too much because I learnt a lot by doing so, and 
because it's a one-off cost that's small in the context of my 
bigger goal.  Had I gone a more enterprisey route, I'd be paying 
a higher price via different means (lower share of the pie, and 
much more friction, wasted time in meetings, and frustration).

And if you have inexperienced programmers (and I tried working 
with one as I was getting started recently, and then before that 
at my fund) then with Python or Go it will go much more quickly 
and easily than with D - because of the language, the docs, and 
the 'diversity' of the community (D caters less in its ecosystem 
to beginners, except in the helpfulness of people in the forums, 
which is quite a lot, but not enough to offset the other things).

"I was

 thinking of D specific reasons like lack of support for mobile 
 platforms (not 100% yet). So your average stock broker couldn't 
 calculate some bogus numbers on his iPad while having a latte 
 and a Pelegrino in a posh cafe off Wallstreet. He he he."


I wouldn't include that in a talk as anyone who comes is not 
likely to be open to using D primarily for mobile platforms.  
Like if that's the deal-killer, why would he come?  And my guess 
- without knowing much - is that this is a matter of a little 
time, and in a year or two it will be good enough to write some 
basic apps.

BTW financial people may not be quite as your image of them might 
be.  On the hedge fund side there is an inordinate number of 
exceptionally smart people.  My old boss came top in his year in 
maths at Cambridge, and when I asked his Directory of Studies 
where I could find another chap of his ability amongst recent 
graduates, he laughed and said a man like that comes along only 
every few years if you are lucky.  He's now a machine learning 
researcher back at Cambridge.  And there are many others like 
him, or perhaps even smarter, that you never hear about.  Michael 
Hintze is one that has a public profile.

A chap I worked with 20 years back linkedin me to thank me for my 
posts on D.  He was a pretty successful trader that ended up 
setting up a market-making business, but even a few years in he 
felt a degree of mental pain financially.  Because he had turned 
down a personal offer from Bill Gates to work with him (they 
didn't hire dummies, certainly then), and the stock from his 
signing on bonus would have been worth $20mm.  He's for now less 
interested in programming as he is learning Greek to take 
advantage of opportunities there.

There are even many smart stockbrokers (although it's been a less 
cerebral job) because the collapse in commissions amidst a 
lower-volume environment has been brutal and best execution means 
the old relationship stuff is rather different.  So to survive 
you have to be a different kind of person than the guys that 
flourished before.


 GC and lack of mobile are real reasons not to use D.


Depends what you are trying to do!  If you aren't writing mobile 
apps (as I'm not on a horizon that matters for planning) and 
don't care about latency there are still many questions to think 
about.  I've had to think about this from another perspective 
lately, as I need to see whether it makes sense for my client to 
consider starting to use D inside the organization in some ways, 
and I'm not going to last very long and it wouldn't be the right 
thing to do if I suggested he should use D just because I happen 
to like it..

BTW if you would like to chat about natural language processing, 
please drop me a line by email.


Laeeth.
Nov 04 2015
parent Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Wednesday, 4 November 2015 at 12:08:19 UTC, Laeeth Isharc 
wrote:
this hardly matters for Java, C++, Python etc because mostly you 
won't need to use a bunch of different libraries.

I meant mostly you won't need to go outside that ecosystem to use 
a bunch of different libraries whereas with D probably you will - 
and whilst it is not very difficult, writing it in D as a 
beginner or intermediate level programmer and calling a C library 
will take more time and effort than a guy of the same level doing 
the same in python (and I expect Go).  Doesn't mean you shouldn't 
do it if you're going to use the library intensively - it's a 
price you pay once, and it might be small in the bigger picture - 
but if you are using a gazillion different libraries, each of 
which will need to be wrapped, you might want to think about 
whether D is the right tool for that task.
Nov 04 2015
prev sibling parent reply Laeeth Isharc <laeethnospam nospamlaeeth.com> writes:
On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.


Sorry - I wrote this in a hurry, and I should have said on my 
experience of using D in finance (not the whole sector, which is 
absolutely enormous and very diverse), and what lessons and 
general things might be useful for others considering D.

I can imagine lack of fixed point might be a problem.  Shouldn't 
this be in Phobos?  If BigInt is, then why not fixed point?  
There is this library here - had some problems compiling it last 
time (dmd versions), but it seems at least somewhat 
thought-through:

https://github.com/jaypha/fixed

Not sure if I replied to the suggestion that D isn't suitable for 
enterprise use.  That's a word with a nice penumbra of 
connotations.  If you mean you shouldn't use it for a project in 
a multinational where thare are 100 people working on it and 
without extensive experience of using D by the key people 
already, then sure.  If you mean that D isn't suitable for 
serious work where there are very large amounts of money at 
stake, and the organisation may be a decent size then I strongly 
disagree.  The examples of Facebook's worp, Sociomantic, EMSI, 
and the German guys who do the Norwegian train system ought to be 
sufficient to make that point...
Nov 04 2015
parent rumbu <rumbu rumbu.ro> writes:
On Wednesday, 4 November 2015 at 12:25:31 UTC, Laeeth Isharc 
wrote:

 On Friday, 30 October 2015 at 10:35:03 UTC, Laeeth Isharc wrote:

 I'm writing a talk for codemesh on the use of D in finance.


 Sorry - I wrote this in a hurry, and I should have said on my 
 experience of using D in finance (not the whole sector, which 
 is absolutely enormous and very diverse), and what lessons and 
 general things might be useful for others considering D.

 I can imagine lack of fixed point might be a problem.  
 Shouldn't this be in Phobos?  If BigInt is, then why not fixed 
 point?  There is this library here - had some problems 
 compiling it last time (dmd versions), but it seems at least 
 somewhat thought-through:

 https://github.com/jaypha/fixed

 train system ought to be sufficient to make that point...


This module is nice (except the fact that's using std.math.lround 
all over the place which is available only on Linux) but, as I 
thought, keeping just a scale is not enough for multiplication or 
division:

Fixed!4 a = "1_000_000_000_000.0000";
Fixed!4 b = "0.5000";
Fixed!4 c = "2.0000";

writeln((a * b).asString) will output -53402322211.2865
writeln((a / c).asString) will output 38831398157.2612

That's because we have a multiplication overflow in both cases.
Nov 04 2015