On Wed, 19 Jun 2013 20:25:41 -0700 "H. S. Teoh" <[email protected]> wrote: > > Thanks for your clarification! This is much more helpful than the > definitions of TDD that I found online (e.g. on Wikipedia). > > I will say, though, that this seems to be just Yet Another Buzzword > for "API design". (I'm automatically skeptical when buzzwords are > involved, because all too often, buzzwords are employed to make > something rather ordinary appear to be special.)
I feel the same way. > OTOH, not all APIs should be designed to cater to the users' POV. I've > encountered APIs that were *not* "convenient" in the way that I had > preconceived, but in the end, it turned out that by forcing me to do > things the "inconvenient" way, it not only opened up brand new ways of > thinking about the problem, but also guided me into approaching the > problem from an angle that is *efficient to implement*. It's just like > Knuth said: > > "People who are more than casually interested in computers > should have at least some idea of what the underlying hardware > is like. Otherwise the programs they write will be pretty > weird." > > So I think a balance needs to be struck between what users would like > it to be, vs. what is a good way of approaching the problem. API's > should not be so far removed from their implementations that the > resulting code becomes "pretty weird", as Knuth puts it. TDD is good > and all, but there's the danger of pushing it too far and applying it > where it's not applicable. > Right. It's like creating a Vacuum Cleaner or a car or a kitchen appliance by designing the case, housing and controls first, and then trying to design working internals to fit that mold. Form needs to follow function.
