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.

Adam D. Ruppe wrote:
> 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.

Thanks for letting us know about this. Good stuff!

On 12/23/10 4:49 PM, Adam D. Ruppe wrote:
> Andrei Alexandrescu wrote:
>> I think the bread and butter support
>> is as rock solid in both languages.
>
> I agree. For my day to day work, I'm pretty conservative in the
> use of the language; 90% of my code is probably best characterized
> as "a better C".
>
> Interestingly though, I use a template of some sort about once
> every five lines... Variant.get, std.conv.to, my own mysql.query,
> and several other little ones get heavy, but discreet use.)
>
> Anyway, I very rarely encounter D bugs in any of the code, and
> virtually never in that simpler bulk of it. The edges may be
> rough, but the core kicks ass.
>
> I've spent less time fighting bugs in the last year of D than I
> did reading php.net/strpos and php.net/str_replace in the previous
> year of PHP!

This post is a breath of fresh air (as is the subsequent expanded one).

There's a risk on this newsgroup to get stuck in a sort of limbo mode, in which the analysis of increasingly narrow corner cases loses focus on a few larger issues. Granted, we _must_ leave no nooks and crannies unexplored, but we also shouldn't spend disproportionate amounts of time on those at the expense of getting work done in D.

D is a great language to work in /right now/. It has amazing capabilities, allows defining complex designs with ease, and it's a pleasure to code in overall. We need a fair amount of more good quality libraries, most of which can be written with the current implementation of the language. We could also use success stories of use of language for writing compelling programs. All of these are possible _today_ even if e.g. lazily updated (memoized) members in otherwise const structs and classes are not yet available.

Spending inordinate time worrying about fractal details may take one to the point where all work is paralyzed by endless dwell in the "design study" land. As inevitably most design decisions involve tradeoffs, the one way to see if it all works is to get work done in the language.


Andrei

On 12/27/2010 02:16 PM, Andrei Alexandrescu wrote:
>
> There's a risk on this newsgroup to get stuck in a sort of limbo mode,
> in which the analysis of increasingly narrow corner cases loses focus on
> a few larger issues. Granted, we _must_ leave no nooks and crannies
> unexplored, but we also shouldn't spend disproportionate amounts of time
> on those at the expense of getting work done in D.

Funny, I thought the people trying to write const correct libraries and multithreaded programs were trying to get work done in D. Immutability was supposed to be the crown jewel of D2. Given your past statements, and the recent statements backing down on immutability, especially as it is used in Phobos, a thought occurred to me:

Rename D2 to Icarus, backport the "amazing", working parts of D2 to D1, and rename that to C++0x. Everybody wins.

Sorry to pick on you, Andrei, but with leadership comes responsibility. I also believe in truth in advertising. Walter can't tout immutability as a bullet point if it isn't working, has unresolved design issues, and you yourself have backed away from it.

On 12/27/10 2:48 PM, Jeff Nowakowski wrote:
> On 12/27/2010 02:16 PM, Andrei Alexandrescu wrote:
>>
>> There's a risk on this newsgroup to get stuck in a sort of limbo mode,
>> in which the analysis of increasingly narrow corner cases loses focus on
>> a few larger issues. Granted, we _must_ leave no nooks and crannies
>> unexplored, but we also shouldn't spend disproportionate amounts of time
>> on those at the expense of getting work done in D.
>
> Funny, I thought the people trying to write const correct libraries and
> multithreaded programs were trying to get work done in D. Immutability
> was supposed to be the crown jewel of D2. Given your past statements,
> and the recent statements backing down on immutability, especially as it
> is used in Phobos, a thought occurred to me:
>
> Rename D2 to Icarus, backport the "amazing", working parts of D2 to D1,
> and rename that to C++0x. Everybody wins.
>
> Sorry to pick on you, Andrei, but with leadership comes responsibility.
> I also believe in truth in advertising. Walter can't tout immutability
> as a bullet point if it isn't working, has unresolved design issues, and
> you yourself have backed away from it.

I don't feel you're picking on me but I confess it's difficult to distinguish the good signal in your posts from attempts at irony.

There are also a number of unstated assumptions that are plain wrong. First, to the best of my knowledge immutability has only implementation, not design, issues. As both Walter and I mentioned, those issues are slated to be solved after the 64-bit version is out.

Second, I find it difficult to reconcile my past actions with the notion of irresponsibility.

Third, immutability is not the central feature of D2 as much as aftermath of no default sharing.

Fourth, my "backing away" on immutability is a disingenuous reframing of the simple fact I mentioned: immutability and const offer stronger guarantees than C++'s const and as a direct consequence it will be used less than it. This was in response to people's attempts to directly carry C++'s const-based idioms to D.

I'd be glad to continue this dialog if we could focus on productive topics that are likely to push things towards the better. Thanks.


Andrei