November 8th, 2008
Much of the efforts in modern programming language evolution are focused on moving beyond the low level programming paradigm of imperative programming and into the realm of functional and declarative programming. Imperative programming is simplest way to interact with hardware and generally forms the foundation of higher level constructs. However imperative programming is highly error-prone approach to programming and can obstruct optimizations and implementation opportunities that better abstractions provide.
Functional programming focuses on computations and aims to minimize mutating states. Functional programming avoids side-effects and changing data as the basis for operations. Many computations that might rely on changing variables and state information in imperative programming, can be described in terms of mathematical computations in functional programming. Functional programming may rely on imperative steps in the implementations, but these imperative actions are ideally abstracted. For example, lets take a simple loop that finds all the objects in an array with a price property under 10. In imperative programming, this would be:
function bestPrices(inputArray){
var outputArray = [];
for(var i = 0; i < inputArray.length; i++){
if(inputArray[i].price<10){
outputArray.push(inputArray[i]);
}
}
return outputArray;
}
Can you spot the state mutations that we had to induce in this imperative approach? For each loop we had to modify i (increment it) and for each match we had to modify outputArray (push appends a value to it).
Now if we use a more functional approach:
function bestPrices(inputArray){
return Array.filter(inputArray, function(value){
return value.price < 10;
}
}
This code is completely free of side-effects. We simply described the operation in the form of expressions. The underlying implementation hides all the imperative actions necessary to make this work.
Declarative programming is defined as programming in terms of "what" instead of "how". Functional programming can be categorized as a form of declarative programming since we describe "what" computation should take place with expressions, instead of describing how the computation should be performed in a series of steps as in imperative programming. However, the declarative programming concept goes beyond just functional programming.
One of the central aspects of most applications is persisting data. A core service that most applications provide to users is to be able to store information relating to the use of the application. A social networking application is useless if it can’t actually remember anything about you and your friends. The functional paradigm is limited here, it’s methodology stands in complete opposition to the central goal of the application. Quite simply, applications must deal with mutating states and data. Here we can still apply declarative programming concepts, describing what the data is, instead of how it was created or how we modify it. Perhaps the most critical and invaluable benefit of declarative programming is that the representation of "what" the object implicitly dictates"how" the object is modified . With a declarative approach there is no need for describing how we interact with and modify data, because the structure of the data reveals the how without any further instruction.
JSON provides a great example of declarative programming. JavaScript supports numerous imperative techniques, but JSON is a declarative subset, which precisely defines what an object’s state should be without directions on how to get it there. For example, we could use imperative techniques:
var movie = new Object();
movie.title="Transsiberan";
movie["rat" + "ing"] = 1+2;
movie.setHowLong = function(len){
this.length = len.trim();
}
movie.setHowLong("2 hours ");
This representation describes how to build the state of the object, and can be of unbounded complexity, but it is not actually a representation of the final state. Alternately with JSON:
{"title":Transsineran",
"rating":3,
"length:"2 hours"}
The application of the concept of representation implicitly defining the method of modification can be seen here in the simple JavaScript object. The object’s state is observable as a set of properties and we can immediately infer from the presence of these properties how we modify the objects. We can simply set one of the existing properties to modify the state, and the effect of setting a property is obvious. Conversely, when an imperative approach where opaque object methods are used to modify an object’s state, the effects are not inferrable, one has to refer to out-of-band documentation to understand the interaction necessary to cause a state change.
The other central concept of a declarative approach to data is reversibility . If we modify the state of this movie object, there is a clear unambiguous easily computable representation for the new state of the object with a declarative definition. However, this is not true with the imperative definition. With the unbounded complexity possibilities of the imperative representation, it is impossible to always know exactly when step in the directions needs to modified to correspond the state change.
Another example of declarative programming is HTML. HTML represents the state of the layout of the page. The steps for how to get into a particular layout are not described, the layout is a state that is represented by the HTML. HTML provides clear reversibility as well. Layout changes can be clearly and directly mapped to changes in the HTML representation.
Applications themselves are a form of state as well, both at the low level (code is occupies memory in the form of binary data) and at the high level in languages that reify code. JavaScript is an example of an language where code is data. Here as well, we can benefit from code being organized in declarative approach rather than an imperative approach. An application runtime state that is the result of confusing imperative steps is much more difficult to debug than application that has a clear declarative organization.
Furthermore, declarative programming can often allow programmers to work within a "live" interactive environment, where code can be changed on the fly without requiring a restart. Imperative programming often means that the only way to predictably see the effect of a change in imperative code is to restart. We certainly want to be able to move towards faster development techniques that aren’t stuck in windows-style "restart" cycles.
Once again, declarative programming can be built on imperative programming. If strict discipline of rules is applied to imperative steps, the consistency can yield an declarative form in the context of rules. For example, if we said that all class declarations must take the form assigning a constructor function to a variable and then assigning an JSON object to the constructor’s prototype, then within the context of these rules, we can have a reversible representation that still be used even if we change the state of the class (changing method implementations for example).
It is important that these principles be used to direct our continuing evolution of JavaScript. Techniques like pseudo-classes based on the side-effects within constructor function execution are a regression in the evolution away from imperative to declarative. Prototype-based inheritance does a great job of maintaining declarative programming, as the application itself can be continually updated in interactive code. Debugging can be "live", classes can be evolved without requiring environmental restarts.
