dynamic classes and duck typing

Walter Bright newshound1 at digitalmars.com
Wed Dec 2 03:16:58 PST 2009


retard wrote:
> The thing is, nowadays when all development should follow the principles 
> of clean code (book), agile, and tdd/bdd, this cannot happen. You write 
> tests first, then the production code. They say that writing tests and 
> code takes less time than writing only the more or less buggy production 
> code. Not writing tests is a sign of a novice programmer and they 
> wouldn't hire you if you didn't advertise your TDD skills.

And therein lies the problem. You need the programmers to follow a 
certain discipline. I don't know if you've managed programmers before, 
but they don't always follow discipline, no matter how good they are. 
The root problem is there's no way to *verify* that they've followed the 
discipline, convention, procedure, whatever.

But with mechanical checking, you can guarantee certain things. How are 
you going to guarantee each member of your team put all the unit tests 
in? Each time they change anything?

> In this particular case you use a dummy test db fixture system, write 
> tests for 'a is int' and 'b is int'. With these tests in place, the 
> functionality provided by D's type system is only a subset of the 
> coverage the tests provide. So D cannot offer any advantage anymore over 
> e.g. Python.

Where's the advantage of:

     assert(a is int)

over:

     int a;

? Especially if I have to follow the discipline and add them in everywhere?



More information about the Digitalmars-d mailing list