How is the D programming language financed?
Adam D. Ruppe
destructionator at gmail.com
Fri Dec 24 10:45:33 PST 2010
Trass3r wrote:
>> Yup. I use D almost exclusively in my professional work
> Wow how did you do that?
> People around here don't even know D exists.
One thing that helps me a lot is I'm an independent contractor,
so as long as I give results, I have quite a bit of freedom in
the specifics.
Nevertheless, some clients still are reluctant to try something
new. (Thankfully, the big one I've worked with for a year and a
half was a fairly easy sell! I think the biggest help was his
existing codebase was written by monkeys so ditching almost all of
it was a good decision no matter what language we used)
Anyway, here's how I do it:
1) Be willing to spend my own time on it if something goes wrong.
I spent quite a few weekends doing prepwork before introducing
the big guy to D: I had to make sure it could replace PHP for
the bulk of the project while still being able to talk to PHP
to fill the gaps of what it couldn't do.
2) Write D in a conservative style. Not only does it reduce the
likelyhood of hitting a bug, it also reassures them that any
decent programmer can follow along if you leave.
If they look at it and say "oh looks like a better Java" or
"cool, better C", you're on solid ground - odds are Java and
C programmers can follow along with minimal training, which
means finding a replacement to maintain the code is easy.
But if they look at it and say "WTF" you're out. Ease into the
new features of D. Even being very conservative, you'll see
big boosts over straight up old language so it is still a huge
plus to use D.
I've also found that a surprising number of people have
actually heard of D. I've had three different clients, when
I approached them on D, ask their programmers and get a positive
feeling about it. "My guy said he's heard of it and been wanting
to try it..." here's your chance!
3) Don't be afraid to call C libraries! extern(C) is one of your
best friends. It proves that you can access a great deal of
existing code with ease, putting the library worries away,
and you can write using pretty familiar APIs, so their team is
right at home.
4) Emphasize D's strengths as you talk. Even if it is little,
draw some attention to it. Make sure they know the move to D
provided direct benefits. (And no need to mention D bugs if you
do encounter them, just work around it, but they really are rare
and easy to work around in conservative code.)
An example of this, I point out compile errors in chats. "Thanks
to D's static assert, we can deploy to a new customer with
confidence that all needed configuration values are set before
testing."
In short, ease them into it and reassure them that it is a low risk,
beneficial change. Start small, with something like helper scripts
before trying to introduce it into a bigger project, so they know
it can and has done real work for them before.
More information about the Digitalmars-d
mailing list