Constraints Revisited

In search problems, you often have a great many potential solutions in your space that never need visiting. Many of these solutions are obviously contradictory, and can be discarded early. By applying constraints and enforcing consistency of constraints on your solution space, you can prune off contradictory solutions before starting your search. Thus, can many problems with exponentially large numbers of potential solutions be reduced to much smaller, much more tractable problems of fewer solutions.
There. I said it.

Update: My constraint library is going well. I think it is approaching actual usefulness. Yesterday I fixed my domains so that they can contain arbitrary disjoint ranges of values; like unions of a bunch of different intervals. Today I'm implementing iterative depth first search, and the corresponding tests, as well as a couple new constraints like allDiff and notEq. Using operator overloading in Scala, constraint problems look like this:

val a = problem.newVar
val b = problem.newVar
a + b := 20
a - b := 10
problem.solve

and then you inspect the resulting values of 'a' and 'b' to find out what the solution is. Right now, since I don't have the search implemented and can only propagate constraints upto arc-consistency, problems like the above don't return a definite answer, just a range. But other problems that aren't so tricky do generate definite answers, and in any case, the current implementation correctly narrows the potential solutions for 'a' to "10 < x < 20" and for 'b' to "0 < x < 10". Since the naive alternative is an infinity of integers, you can undoubtedly see the utility.

Other Interesting Things:
I used TDD to begin the project, and I'm pleasantly surprised. It seems almost the natural way of doing it: stubbing out your project with client code (in test form) gets the ball rolling and the mental wheels turning. If you don't know where to start, pretend you already finished and write some tests to make certain you did a good job. They fail, you fix. No more staring at a blank page.
And unit tests are life! I think I would die if I had to do a project without them. I'm starting to find that the more unit tests I add, the better I feel. It's like a drug. Write the test, fix the bug, refactor rinse repeat. Soon I'll be one of those guys who has to have 100 percent code coverage. Nathan Hungry. Nathan Want Code Coverage.