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
C# - built-in decimal data type 128 bit (96 bit significand + 32 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) 
are true of C++, C#, Java etc. too. It's a bit generic. 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.

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) 
 are true of C++, C#, Java etc. too. It's a bit generic. 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.

 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) 
 are true of C++, C#, Java etc. too. It's a bit generic. I was
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