After over a decade of writing software, I'm willing to accept this up-front cost in favor of long-term (and often short-term) gain. Sure, I can quickly hack out code when I'm not writing tests, but long term experience with both methodologies has demonstrated to me that it's not worth it.
Like many other 'methodologies', it has uncritical advocacy. (http://blog.objectmentor.com/articles/2009/10/07/tdd-derange...) (HN discussion: http://news.ycombinator.com/item?id=866707)
I agree that automatic testing is nearly always a net gain, but using tests themselves as the primary driver for the design process suggests to me that the developer has little other design experience to draw upon.
Secondly, I've realised that when I don't write tests I code too fast. TDD acts as a constraint on myself, something which stops me from running ahead of myself and forces me to stick around a particular problem area for long enough to understand it better, and often learn something that otherwise I'd have missed.
I don't remember ever reading a blog claiming that would be an advantage of TDD before I started.
Extreme Programming was cognizant of this effect quite a while ago. (Actually all of the parts of XP were supposed to have beneficial side effects that reinforced the other parts.)
I agree with the original poster -- it's important to slow down and think about the problem. Then again, I'm a big fan of trying hard not to write code you already understand too well -- that means that you're repeating yourself :-)
Prolog is far from perfect (its default search mechanism gets stuck in left-recursive clauses), but it's a start, and computers have gotten considerably faster since the 70s...
AFAIK, the best known success of declarative programming is writing a pattern matching specification (with ML, Prolog, Erlang, Haskell, or various Lisp macros) and compiling it to the necessary nested if / switch statements, rather than generating it by hand. I guess it overlaps with parser generators, and some other DSLs, too.