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.
