The Declarative Mindset

I’ve been playing around with web-programming lately, and it’s interesting to see how a little declarative thinking can help improve your code.

The declarative mindset

First, let me specify my viewpoint: My interest in declarative programming is not primarily from a programming language point of view (at least not in this context). I care about it from a programming mindset point of view.

The easiest way to define declarative programming is to say it cares about what to do, not how to do it. There is more to declarative programming (and the languages) then that, but for me this captures the essence, and this is the kind of thinking that can help improve our code.

Example

Let me start off with a little example. Let’s make a menu bar in Html.

 <div style="text-align:right;
    background-color:#dddddd;
    padding-top:2px;
    padding-bottom:2px;
    padding-right:4px;
    border: 1px solid #666666;">
  <a href="home.html" style="color:#666666;
    font-weight: bold;
    text-decoration:none;
    padding-left:6px;
    padding-top:2px;
    padding-bottom:2px;
    BORDER-LEFT: #666666 1px solid;
    text-decoration: underline;">home</a></li>
  <a href="login.html" style="color:#666666;
    font-weight: bold;
    text-decoration:none;
    padding-left:6px;
    padding-top:2px;
    padding-bottom:2px;
    BORDER-LEFT: #666666 1px solid;">log in</a></li>
  <a href="news.html" style="color:#666666;
    font-weight: bold;
    text-decoration:none;
    padding-left:6px;
    padding-top:2px;
    padding-bottom:2px;
    BORDER-LEFT: #666666 1px solid;">news</a></li>
  <a href="contact.html" style="color:#666666;
    font-weight: bold;
    text-decoration:none;
    padding-left:6px;
    padding-top:2px;
    padding-bottom:2px;
    BORDER-LEFT: #666666 1px solid;">contact</a></li>
 </div>

Html is a declarative language in itself, so this is by default declarative. But strict a definition isn’t very useful here. I want to improve my coding, not adhere to a definition. So let’s try to improve this code with thinking “What to do, not how to do it”. What do I really want to do here? I simply want to make a menu bar with clickable items. Nice. And this code tells me nothing about how I do it? Well, it actually does. It tells me quite a lot about how it is supposed to look.

Let’s use a separate css-file to extract the “how it looks”-part from my declarative menu bar-code.

  <div class="menuline">
   <ul>
    <li><a href="home.html" class="current">home</a></li>
    <li><a href="login.html">akvareller</a>log in</li>
    <li><a href="news.html">news</a></li>
    <li><a href="contact.html">contact</a></li>
   </ul>
  </div>

That’s better. Now there is not much “How” left in my menu declaration. It’s mostly “What”: A menu bar with clickable items.

Notice that the css-part is also by itself declarative in the strict definition, but for our usage that information is not declarative when we want to define the “what”-part of the menu bar.  Again, the important thing here is not to define what declarative really means in programming language terms. The important thing is to see how it makes us think when we code, and how that mindset affects the code.

Advantages

This is of course a trivial example, and most of us already separate a lot of looks-code into css-files, maybe even without reflecting on why. My point here is not to talk about how to best use css-files. My point is to reflect on what this “declarative mindset” actually does in a broader sense. In my opinion, it has several positive effects on the code, including:

•  Readability
  • The second coding example is easier to understand than the first. Frankly, the first example is a bit of a nightmare. Code that is easy to understand is flexible because it is easy to change. And let’s face it, it makes a developers life better. We all know that code that is hard to understand is hard to work with.
• Ease of use
  • It should be easy to write code. Writing the “what”-part of the menu bar certainly is easier in the second example than the first. It’s easy to write new code, and it’s easy to change the code. Even the “How it looks”-part of the code will be easier in the second example. It’s tidier.
• Separation of Concern
  • This is one of the fundamental design principles in programming. In our example what we have done is actually to separate the “What”-part from the “How”-part. Thinking this way makes us automatically separate concerns.
• Reusability
  • Of course, factoring out all the looks of a menu bar makes that look easy to reuse elsewhere.

Taking it further

To be honest, I’m still not satisfied with the html-code defining the menu bar. Still there are some list item-tags there that really don’t say anything about what this is. I’m actually also a bit skeptical to the a-tag as it is a bit too technical to clearly define the “What” of this menu.

I want to take it further. Now I want the declarative mindset to help me think more in terms of concepts and abstractions. That is what this is about. The more I speak in general terms, in concepts and abstractions, the more I focus on “What to do”. The more technical it gets the more I focus on “How to do it”.

Let’s implement this in Asp.Net and see if we can get any further:

<menu:Menubar runat="server" ID="menu">
  <menu:MenuItem Title="home" TargetPage="home.html"/>
  <menu:MenuItem Title="log in" TargetPage="login.html"/>
  <menu:MenuItem Title="news" TargetPage="news.html"/>
  <menu:MenuItem Title="contact" TargetPage="contact.html"/>
</menu:Menubar>

Remember what we wanted to do? “I simply want to make a menu bar with clickable items”. This code does exactly that, and nothing more. The menu bar has a type that defines everything about its look; the items have a title and a place to go to if they are clicked. That’s all. Now we really describe concepts. The technical “How”-part is completely in the background. The technical details will of course have to be implemented somewhere, but here is the beauty of separation of concern: It is to be implemented somewhere else. When we work with this part of the code, we do not have to worry about it. When we work with that part of the code we do not have to worry about this part of the code.

Bear in mind that this is a mindset and not a language-thing. Separation the “what” from the “how” can be done in any language.

The funny thing about the declarative mindset is that the resulting code looks quite like code that a good object oriented mindset would create. Come to think of it, that’s probably why I like it so much in the first place.

- Tore Vestues