Consider your program a model of the problem that you are automating. Depending on what you are modeling, different paradigms and styles of program will help i

Consider your program a model of the problem that you are automating. Depending on what you are modeling, different paradigms and styles of program will help in different ways. What we call functional programming today is often reducing the problem down to the easy parts. Which is great and should not be discounted. But don't think of it as any more valid of a solution than anything else. And pure numerical models of the problem can often be just as fruitful in solution speed, while being utterly foreign to most programmers. OO gets lambasted as you try and model each individual thing in a problem. In my mind rightfully so. That said, it is very common for us to model things in a way that is very "object" based. Consider the classic model of an elevator system and how that is coded by most people. You will have a set of elevator objects with states that they currently represent. But, you could also do this fully numerically with a polynomial representing things. Expand your toolset to use generating functions, and you can even start building equations that can count the number of solutions at any given state. Still just a symbolic model, but very very different from the OO or even FP style of model that most programmers will write. Better for the problem you are solving? Probably not, during the exploration side of things. But get the problem into a formulation that you can translate into a SAT style, and you can feed it to SAT solvers that are far more capable than programs most any individual can write. Translate the solution back to your representation for display to the users. (Or just general use in your program, as you move to the next thing.)