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