On Friday, 28 July 2017 at 14:58:01 UTC, Ali wrote:
While the Orgs using D page is very nice ... I hoping to hear
more personal stories ...
So
How do you use D?
In work, (key projects or smaller side projects)
in your side project, (github, links please)
just to learn something new? (I would easily argue that
learning D will make you a better C++ programmer, maybe not the
most efficient way, but I a sure it i very effective)
Did you introduce D to your work place? How? What challenges
did you face?
What is you D setup at work, which compiler, which IDE?
And any other fun facts you may want to share :)
I started programming in 1983: BBC BASIC, 6502 assembler, Z80
assembler. I learnt to program C on an Amstrad PCW running CP/M,
and compiler I used had K&R style declarations.
Then I discovered economics, and my life took a different course.
I moved into trading and managing money, but I always programmed
on the side to help me solve investment and business problems.
Kept it quiet because programming was for a long time low status
and clashed with what people expected to see in a money manager.
Late 2013 I recognised that the way our business used technology
was completely broken. The only way to make the most of
technology is to combine an understanding of investing, financial
instruments, the investment business, and technology in one mind.
But where am I going to find a guy like that? So I looked in
the mirror and realised I had to brush up my skills.
So I started building tools to help me invest. My friends mostly
thought it was a crazy course of action, because it's rare if you
leave investing even temporarily to return to it, and I love
markets, but sometimes the direct approach isn't the right one.
We're drowning in data but don't have good tools to make sense of
it.
I learnt python and cython, but kept looking, because I wanted to
have my cake and eat it. Why can I not have all of productivity,
performance, static typing/correctness, abstraction, and code
readability - I don't think I should have to choose just a
couple, and I am not going to. That led me to D in 2014.
At school they used to ask us if everyone else jumped out of the
window would you do it too? And it's a profitable approach in
financial markets to develop and learn to trust your own
judgement of things. If a highly respected and very
knowledgeable economist tells you "you do realise that there is
no basis in economic theory for what you are suggesting", you
need to be able to revisit your thinking, see what you might be
missing, but in the end trust your own judgement over that of the
putative expert. And he subsequently wrote a very impressive
explanation after the fact of how what "couldn't be justified in
theory" did in fact happen. And it's a bit similar with
programming language choices and such. Its way better to appeal
to people who make up their own mind and bear the consequences
then to those who have to cover their behinds by getting the
right ticks in the boxes because the are never going to be
earlier adopters except through some unfortunate accident -
because you also don't want such people as early adopters!
Since then, one thing led to another, and I ended up hiring a few
people from the community to help me as consultant developers.
Maybe a bit more than 10% of Team Phobos, based on a simple
calculation.
I have also ended up running technology, amongst other things,
for a decent size hedge fund. I am using D for the project I
started beforehand, and we are starting to explore its usefulness
in the rest of the firm for some core analytics. It pays to
start small and build on early successes.
Has D been good for me? What have been the consequences of the
French Revolution? In both cases it's too early to say with utter
confidence since life is complicated and things are not always
what they seem to be in the moment, but I have a view on the
latter, and I think the answer to the former is definitely yes.
Finance used to be relatively at the leading edge. The industry
got a bit too fat, it hired the wrong people as it expanded too
quickly, and then after the crisis people had other things to
worry about - first survival, and then an exploding burden of
compliance. At one big bank even the compliance people complain
about the number of compliance people they have. On top of that,
there's so much legacy systems that it can be very difficult to
do anything creative or new.
So as an industry we fell behind a bit, and when you go through a
cycle like that if becomes somewhat self-reinforcing. To turn
things around you need to hire very good people, but it's not so
easy to find very good people who are willing to work with the
people who created and tolerated the mess in the first place.
But it can be done, and I think based on a view from afar that
the banks will do better on this front than they have been.
For a firm like the one I am involved with its different because
we are at a post startup stage. Some legacy but not that much,
and it's possible to do new and creative things. And it's also
possible to use languages that might not win on social factors if
based on intrinsic factors it's by far the best answer for us.
And we don't need to make a big bet, because we can make a start
in a small way for us, and build on successes.
One of the biggest benefits from D is I think a cultural one.
We're in an age of specialists and of the full stack overflow
engineer, with people strapping together ready made components.
If that's all programming is about, you don't need to have people
with flair, because it really flattens out the differences
between people.
But in a business that's highly dynamic, there's also a cost to
such a conventional approach. One loses some ability to adapt to
unanticipated change, and you lose coherence in understanding
about the total behaviour of your system, and about what the
choices are and what the implications might be. This
fragmentation of knowledge that accompanies micro-specialisation
isn't entirely healthy. And maybe if working with framework X
for years will make you faster then someone who hasn't experience
of framework X, speed of development isn't from a commercial
perspective the only, or sometimes the main factor, in
determining productivity, which is not a materialist measure
(features accomplished per 40 hours), but a measure of economic
value added per unit input, and value added relates in this case
to long lived capital, and part of the value of capital relates
to optionality and the ability to adapt what you have built to an
unexpected need, or to change the way you do things in a way you
didn't originally plan for but that's better.
In other words you can think about the plasticity of D from the
point of view of real options theory.
When I started my career there was an understanding that whilst
experience had value, someone capable could often pick things up
given a few pointers and a chance to learn. We somehow forgot
that in the years since then, though this way of thinking is
making a comeback.
So a benefit of D is that because it attracts people who aren't
put off by the tooling etc, one tends to find people who are
adaptable and don't mind getting their hands dirty and doing
something they never did before because that's what is the most
valuable right now from a business perspective. Lack of polish
can itself also be a highly effective filter.
Many seemingly hairy things are not that bad with a bit of
experience. But if you don't get such experience because you
spend your life in an environment where things just work then
when something doesn't work it's a bit more painful.
Suppose there's part of an application that's slow. I simply
can't imagine finding a good and experienced D developer who
wouldn't have put it through a profiler and doesn't already have
some idea anyway of bits of the code that are slow. In some
other communities, it really isn't like that at all! And
similarly if you think the GC is a problem in your code somewhere
it's just normal to use the instrumentation to check and to use
an allocator if that's the case. Not something you would even
give a lightning talk about doing in D land, because it's just
what you do. For some managed languages the norm is quite
different.
London used to be a set of villages. But today any former
village that has an underground station has lost its character,
whereas those that don't are harder to get to and have somehow
preserved it more. And it's the same with virtual communities -
the very difficulty initially of gaining entry can also preserve
its character.
Benefits of D? The easiest reasons to adopt something are not
necessarily the reasons that ultimately matter most. Some
proximate attractive aspects of D are the ability to write native
code in a modern language that can be called from many different
languages with wrappers being generated via attributes. Excel-D
is one such tool, but there are other languages we need to target
also.
There's a rising interest in alternative data sources in finance.
Numerical data is not that big. Text data can be, if not big,
uncomfortably large vs what we are used to working with. And D
is fast with strings, but that's not the case for some other more
modern languages used in a finance environment.
Code clarity is worth something too. It's easy to read
well-written D code, to some extent even if you don't know D.
Some other languages not so much, because of the fragmentation of
OO code and the verbosity and use of abstraction that isn't doing
any useful work but does constitute another layer in the way of
understanding what's going on.
I personally use Sublime or vim on Linux. Others use Visual D.
Biggest challenges? People don't have reference points for D. It
doesn't slot into an existing mental category. "so you're saying
D is good for larger data sets". Well, that's true but it's not
quite only what I am saying.
Other challenges - normal human anxiety about doing something
different. And habit - apart from necessity, the most powerful
force in the universe. If someone is in pain, they are going to
listen to something that might be an answer. C++ programmers I
work with aren't sceptical of the GC, but they're excited about
doing things better because they both love C++ and appreciate
that it has flaws.
Windows experience is not that great. Part of it is just native
code on Windows rather than D, but expectations are set by
languages that do everything for you. Most of the time
installing a library in python is one command. In D you might
have the dub wrapper or binding and then the C library itself.
And installing the latter is not always just one command.
Would be great to have a web front end to D irc, because some
companies have to be careful about what chat services are
accessed from their systems. Of course I can for me set this up
myself but others might not bother to do that.
Thinking about my own experience and that of another commercial
user I wonder if there is a market for paid support for compiler
plus phobos plus certain libraries. The first adopter within a
firm might be quite ready to persevere, but the others they
follow may do better if there is someone they can call when they
get stuck. Not necessary for my group, but in time some might
find it valuable. Not very difficult but just need patience and
ability to communicate.
Maybe some value also to training eg python users to show them
how they can do similar things in D and what the benefits are.
People learn in different ways and I think it's a minority that
learn from reading books unless very motivated.
