Why we chose not to use D for our Linux project

[Nick Sabalausky]

"Daniel Giddings" <daniel.giddings at gmail.com> wrote in message 
news:g0vmk1$1qfk$1 at digitalmars.com...
> Clay Smith wrote:
>> Chris R. Miller wrote:
>>> A very good friend of mine and an absolutely fantastic programmer once 
>>> told me some great advice: stop making stupid UML diagrams and write 
>>> code!
>>>
>>
>> Sorry, but I have to say that you are not getting great advice. The 
>> design stage is the most important stage in the life of a program. Get 
>> that wrong and you can write all the code you want, and it will all be 
>> wrong.
>

That would certainly be true if you're using the waterfall method.

> Your first design will either be wrong or take forever! (at least a lot 
> longer than it need as you make decisions based on lack of experience with 
> the problem)
>
> Better to start with a minimal design and then prototype and iterate. Set 
> up your development process to deal with design changes and code 
> refactoring.

That's been exactly my experience.

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.

Forcing a long code-less "design" stage is like agonizing over your code 
before compiling to make sure there's no syntax errors. Just compile the 
damn thing. It'll tell you if it's wrong (provided the language doesn't 
suck, but that's a different discussion ;) ).

That said, there are times when it can be good to sit back, think, and not 
touch the editor. But the real test to see how much 
"think/paper-n-pencil/UML" you should be doing, versus 
"implement/prototype/iterate" 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. But more often than not, anything you can play 
around with in UML structure diagrams is also going to be very easy and 
productive to play around with in actual code, even if you have to use a lot 
of stubs for "to-be-implemented" functionality.