People who discuss programming often talk about the distinction between declarative and imperative programming as two different paradigms. However, in this post, I argue that these terms are really only relative and informal, and in fact that we don’t lose much if we de-emphasize the distinction.
Typically, one way of introducing these concepts is via examples, like HTML (for declarative) and Java (for imperative.) However, in reality, the distinction is really one of high-level versus low-level. If we take a vantage point that is low-level enough, then even Java can be seen as “declarative.” For example, from the vantage point of machine code, Java statements are not describing how something should be done, since they may not map 1-to-1 to machine code instructions; rather, they are describing what should be done, and the Java compiler (and ensuing JVM interpreter) are translating the “what” into the “how.”
In fact, really the distinction between “what” and “how” is one of interface versus implementation. Most generally, an interface can be defined to be a specification of a contract, which contains an expectation of the “what”; then, an implementation is something that fulfills that contract, and in doing so must answer “how” it achieves that fulfillment.
Going the other way, HTML might seem declarative since we can simply write <input ...> and get a field that accepts user input, but from the vantage point of a WYSIWYG or no-code web development platform, like Adobe Dreamweaver or a CMS like WordPress, HTML seems quite imperative, concerning itself with the nuts and bolts of “how” a website is ultimately built from basic components rather than the content, or the “what.”
Personally, it seems to me that there are many cases in software engineering of a single idea being expressed in different language/terminology in different contexts, and it seems that this distinction between paradigms is one of those cases, being just an example of the basic and fundamental concept of interface versus implementation.
Also, something that I only realized after programming for many years is that when we say “interface” here, that is really an informal notion — it doesn’t necessarily correspond say to a particular interface construct, like the interface of Java. An interface could specify a constraint beyond just “does this class have this method,” and that would go beyond the Java interface: it would actually be an “interface” that is ultimately enforced by the class construct in Java. “Interface” and “implementation” may take on different meaning depending on the context, and it is only under one such meaning (namely, existence of a method with the required signature) that the Java constructs of interface and class correspond to the concepts of interface and implementation (respectively.)
While the usage of the declarative vs imperative terminology makes sense at a time when someone is looking at the “imperative” status quo and developing a “declarative” framework that would massively improve productivity, the reason why I argue this distinction can be dropped is that the “declarative” framework would probably be replaced by something else even more “declarative” later on. In fact, I think that any language would ultimately become “imperative” because humans would use it to build systems to their maximum ability. Humans have always endeavored to push technology to its limits, and thus it makes more sense to emphasize viewing every framework as providing a set of nuts and bolts (the “imperative” paradigm) and then asking, “what all can we do with these nuts and bolts?” The focus on more creative applications of whatever capabilities each new framework comes with can then spur innovation and excitement more quickly. And this doesn’t just speed up doing tasks that humans were already doing, this enables building much larger systems and as a result addressing entirely new use cases.
