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?
