On Wednesday, 19 June 2013 at 21:54:04 UTC, Walter Bright wrote:
On 6/19/2013 4:01 AM, Szymon Gatner wrote:
This is not strictly D related but I am very curious about D's
community opinion
on the points made by non other than Jim Coplien here:
TDD strikes me as an ad-hoc way of constructing code, and is a
poor substitute for thinking about the problem as a whole. For
example, I don't really see how getting a square root function
to pass its test cases is going to lead one to implementing one
of the classic algorithms for computing square roots. I don't
see how TDD for a compiler will lead one to rediscover what is
known about the best way to organize the logic of a compiler.
TDD is "curve fitting" which is what one does when one has no
understanding.
I think their argument would be that if you're only interested in
"classic algorithms" or "the best way" that is known, then you
may not get much out of TDD. But if you're exploring the
solution space and trying to come up with a design that emerges
with use, as opposed to thinking up a complete design in your
head and then simply implementing it, I think they'd say TDD is a
good solution for that.
Sometimes "ad-hoc" or "curve fitting" is a better way to begin,
when you're entering a new domain, ie you don't even know what
the curve looks like, say designing the first social network with
1 billion users. ;) At least that is what I understand of their
method, I've never used it.
