Procedural vs. declarative programming


Steven Pemberton gave a talk at FXPAL today where he talked about the virtues of declarative programming, and specifically about XForms. He cited some interesting statistics about the incidence of errors as a function of the size of the program, including the observation by Fred Brooks in The Mythical Man Month that the number of bugs increases as L1.5. So the way to increase the reliability of code is to reduce the amount of code that has to be written to achieve a particular result. Declarative programming, Steven argues, is an improvement over its predecessors (high-level programming languages, and interpreted programming languages) because declarative programming focuses the programmer’s attention on the application logic and dispenses with worrying about the “fiddly bits.”

He illustrated this claim by describing a (toy) application that allowed pizza to be ordered through a variety of interfaces–the web, the smart phone, a voice-based menu system, IM client–without re-implementing the application. To me, however, these examples illustrate the value of good (programming) interface design and clean separation of concerns, rather than something inherent about declarative programming.

Over the past year, I have been programming in Groovy, a dynamic language implemented on top of the JVM. Groovy extends Java syntax in useful ways, while retaining complete interoperability with java classes and types. One common pattern used in Groovy (and in Grails, the web application framework built on it), is the builder pattern.

Let’s say you wanted to generate some HTML programmatically. Here’s what it might look like in Groovy

 def builder = new MarkupBuilder();
 def list = ['item 1', 'item 2', 'item 3']
 builder.html {
    head {
        title 'A Groovy example'
    body {
        h1 'Example of a list'
        ul {
           list.each {item-> li item}

This code, when executed, will generate something like this markup:

      <title>A Groovy example</title>
      <h1>Example of a list</h1>
         <li>Item 1</li>
         <li>Item 2</li>
         <li>Item 3</li>

I won’t give a full tutorial on Groovy syntax here (other than to assure you that the code above is, in fact, procedural), but it seems obvious that there is a strong correspondence between the code and the emitted markup, and “fiddly bits” of coding HTML are hidden from the programmer. The builder pattern, by the way, is used to construct Hibernate criteria as well.

The point to of all this is that it’s not the declarative nature of a specification that makes it elegant, but rather that elegant specifications often appear to be declarative.

Share on: 


  1. Twitter Comment

    RT @HCIR_GeneG: Posted “Procedural vs. declarative programming” [link to post].

    Posted using Chat Catcher

  2. Twitter Comment

    FXPAL Blog » Blog Archive » Procedural vs. declarative programming: Over the past year, I have been programming.. [link to post]

    Posted using Chat Catcher

Comments are closed.