[gaius]

Strong inferred typing is (generally) superior to static in the sense that it gives you the best of both worlds, flexibility and safety. Strong typing plus a clear separation between pure and impure code gets you a lot. Test harnesses are vital still, but testing blindly (which is what most unit testing does) is scarcely better than old-fashioned manual QA.

[stcredzero]

People forget that the whole point of abandoning strong typing in environments like Smalltalk was the extreme speed of exploratory programming that it supported. If you can have strong typing and have low overhead rapid exploratory programming, then why not? Duck Typing is not a goal, it's a means!

I disagree that testing blindly is scarcely better than manual QA. If it's automated, the cost of leveraging your tests is small. The cost of adding more tests is not multiplied by iterations. With automation, increased frequency of tests can be used to localize the cause of bugs to particular changes in time.

[gaius]

But that's tangential. If you are doing exploratory programming, what does unit testing get you? How can you write the tests before the code if you don't have a spec to work from in the first place?

A lot of the pain of strong typing goes away with type inference - and strong typing means you get much better tool support, e.g. you can see a problem right there highlighted in your editor, you don't need to wait for the unit tests to run on your nightly build!

[stcredzero]

But that's tangential.

Maintenance is tangential? Most of the work across all of the fields of programming is probably maintenance.

If you are doing exploratory programming, what does unit testing get you?

It gets you the ability to change your mind and do deep reworkings of very complicated systems with a higher degree of confidence. It's most valuable for maintenance, while duck typing, however.

How can you write the tests before the code if you don't have a spec to work from in the first place?

You end up doing better interface design at a finer granularity than you would have to otherwise. It slows you down, but requires greater discipline in terms of good architecture, so you end up saving time that way. Test first is really just design-up front, but with 3 or 4 orders of magnitude more iterations.

This is best for duck typing languages. Would I unit test in Eiffel, which supports Design By Contract? Doubt it.

you don't need to wait for the unit tests to run on your nightly build!

In the original Extreme Programming, one ran unit tests before checking in any code!