Traditional programming is traditionally imperative. However, there is always this trend to break away from tradition. In programming, it is always fashionable to practice in so-called declarative programing.
In layman's term, imperative programming focuses on the "how" part of the problem, while declarative programming focuses on "what" part of the problem. That is, imperative approach tries to sketch out the path to solution, while declarative approach tries to transform the problem into a form that is already solved or decompose the problem into compoents that is already solved.
This differentiation is stupid.
Solving all problems requires two stages. The first stage is the analysis stage, during which we tries to understand the problem and sketch out and understand the solution in a analytical way. This stage can take place in one's head or on paper; or one may lay them out in certain frame work, e.g. flow charts, classes and interfaces, conditions and constraints. The second stage is the programming stage, during which we actually sketch out the path to solution. -- Programming is the "how" part!
Declarative style forces our understanding of the problem into an inflexible framework. Isn't that intuitively stupid? Yes, there are problems naturally fit into certain framework, and it is so fit that existing solutions built into the framework readily solves your problem. But this is nothing to be amazed. I have full kitchen of such examples. I have a microwave, all I need to solve my food problem is to lay them on the rotating platform and input the time and power. It sometime works, some time it just doesn't solve my problem satifactorily. The microwave framework solves food heating problem, but sometime our problem is the taste and heat distribution problem. By forcing all my problems into a simple microwave heating problem, sometime it works, sometime it is simply frustrating.
Declarative approach is just that. It is learning the manual and restricting your problems. It is not programming.
Programming is the "how". It is actually doing it. Our love of programming is actually the love of achieving things with our own hand. The happiness, in terms of satisfaction comes from the realizations of optimal path -- not just solutions. Yeah, I understand sometime that we wish we can enjoy the experience of doing things yet bypass the actual work, but truth to realize is, we can't have the cake and eat it too.
Doing things does not exclude using tools. So programming does not exclude using existing libraries or frameworks. However, we should recognize that is always this slope of fitting the tool to the problem versus fitting the problem to the tool. The former is programming, the latter is declarative.