Why we chose not to use D for our Linux project

[BCS]

Reply to Nick,

> 
> No matter what strategy you use, your first approach (or two, or
> three) is going to be wrong, period, regardless of how much thought
> you put into it. It's just a fact of programmer life. So you can
> either waste your time pretending you have a shot in hell of getting
> it right the first time, or you can play around with a compiler
> *while* you're brainstorming to get hard instant feedback instead of
> operating on speculation. A compiler should be one of your design-time
> tools.
> 

I'd love to see a compiler that can pick out the kind of issues I worry about. 
(Logic errors etc.)

> Forcing a long code-less "design" stage is like agonizing over your
> code before compiling to make sure there's no syntax errors.
> 
> But the real test [...] is "How much work will this take to try
> out?" The more work it takes to actually try out an idea, the more
> upfront thought you should put into it.

The prime issue of that is that people don't like throwing stuff out. If 
the developer is very willing to hit delete and go for a total re wright 
the above becomes much more viable. But if they are very willing to munge 
what they have into what they need you can start running into issues: "this 
is the design we have, so lest work with it"

That all said, a lot of the coolest stuff I've done couldn't be designed 
on a blackboard because it's been related to exploring the corners of the 
compiler.