If you're a Ruby programmer, and especially if you're a web developer using Ruby, TDD may well save you time, depending on your style: There is a lot of testing infrastructure, a culture, a bunch of blog posts, a language with flexible syntax, and -- in the case of Rails -- a framework designed with the intent of supporting testing.
Whereas I can't imagine that the average C programmer has an easy time adopting TDD. Surely you don't write unit tests in C? That sounds like hell. But if not you have to learn some other language, and write your tests, and integrate them with your build system. And no matter what you do, every build takes a certain minimum amount of compile time and link time... That might be pretty fast in these enlightened days of multicore processors, but let's just say that I'm not surprised that (e.g.) Jamie Zawinski didn't invent TDD for C in the early 1990s. He'd still be waiting for his test suite to run.
TDD is a necessarily new invention. Imagine trying to explain it to the punch-card coders of the 1960s, when computer time was a precious resource that you signed up for an hour at a time in advance, perhaps days in advance. Those folks sweated blood over every line of code, trying to find and fix the bugs before it ever ran. The idea of deliberately breaking your code and then fixing it, over and over, would have been crazy.