good reasons not to use D?

[Laeeth Isharc via Digitalmars-d-learn]

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.