Imperative and Declarative Programming
I had a talk recently about what kind of idioms I’m working with on my JS journey.
Those of you who have been following me for some time know how big of a ReactJS lover I am.
The reason I love it so much isn’t because of the underlying performance (thanks Virtual DOM), the all-in-one-file component programming, nor the beautiful JSX syntax.
It’s much more about the declarative way of writing JS.
Declarative UI
That’s the main power of React. You write down what your page should looks like, and not how to render it.
View = Render(Props)
This allows you to clearly understand how your UI works. A simple glimpse at the code by literally anyone that barely reads english is enough to get the logic behind the component.
This has several benefits :
- You don’t care about the actual rendering implementation. This is what allows React code to be used in Browsers, Mobile apps, Desktops, Embedded Systems and Video Games (I recall it’s been used in Battlefield UI but can’t find the video).
- Your code is more predictable
- You drastically reduce the complexity of your program
Let’s move on the differences and how to write declarative code.
The difference
Did you do some C ? Even better, did you do some Assembly ? Recall how you had to write down everything the computer is supposed to do ? Likely, “take this number, put it in the register, add 5 to it, get it back to RAM”, and so on.
The programming technique of dictating the computer how it should work is called Imperative Programming.
There is an other way of writing code, that consist of writing down the result you want to achieve instead of steps that are involved to get it. This is called Declarative Programming.
In Imperative Programming, you write down how to do it.
In Declarative Programming, you write down what you want.
Let’s take a live JS example.
This dummy code takes an array of elements, and return the sum of every even number, and multiply it by 2.
- The Imperative Way : by reading the code, you can understand what it does, through the intent is not clear : why are these steps involved, what does it relate to ? It’s a bit difficult to read, so imagine a longer snippet of code.
- The Declarative Way : it starts to make a little more sense. You take all the numbers, you filter out those who are odd, then you double the rest and sum them all. It’s also more concise and the steps involved into getting the result are clearer.
- The Point-Free Way : ok this one might sound “a bit too much” but go along with me for a second : the code is basic english. In the previous code, you have to deduce “i % 2 === 0” returns true only if “i” is pair. You have to deduce that “i * 2” means “double i”. And you have to deduce what reduce does, and that “acc + next” means it will add the current number to the previously computed sum. You constantly have this process of mapping your code to its meaning, in your mind, because you think in term of words, not lines of code.
In point free, you don’t have to translate code into thoughts, because it’s bare english. It says : “take all the numbers, filters out those who are odd, double them and reduce them to a sum”. You’ve resumed 6 lines of imperative code up to 1. Less code means less bugs right ?
And there I can already hear you :
But declarative programming still uses imperative programming under the hood, so it’s impossible to write pure declarative code !
That’s not false. Computers don’t understand declarative code, they are machine you ought to tell their duty, and how to do it, step by step. But the main point is not to write pure declarative code, it’s to push imperative code to its limits : the implementation detail.
Take back the example of React. By itself, it’s just a descriptive UI lib, it translate your JSX into functions that create React elements. It manages the lifecycle of those components, and that’s basically it. The real magic is done by the renderer.
This flexibility allows React to be portable in all the environments I’ve described above. It allows React maintainers to focus solely on the components and their work.
Going further
It’s difficult to talk about declarative programming in JS without talking about functional programming.
Functional programming is a programming style in which software is built by composing pure functions, avoiding side-effects and using immutable data.
Ok that’s a lot. Let’s break this down :
- Recall your mathematical courses ? function composition is the process of using the result of a function as the input of another function, typically x = g(f(x))
- A function is pure if two conditions met : it return the same output given the same input, and doesn’t have side effects.
- Side-effects is any action within a function that acts on external state (outside the function), or has any observable effect outside the function.
- Immutable data is any data that once set cannot be updated.
Take for example our functions isPair, double and sum. They all respect every rule of functional programming : they are pure. This is what makes them readable, predictable and testable.
Functional programming is a declarative programming style by nature. One cannot talk about the one without mentioning the other. One can do declarative programming without using functional techniques, but combining both gives you hell a lot of power.
If you’re eager to go further, have a few read :
You might want to even further and check Reactive Programming, which is yet an other thing to put on top of your declarative stack.
Distinguish the various paradigms
Declarative Programming is opposed to and only to Imperative Programming. That is, you can typically combine both of them with every other programming styles, such as those I mentioned. It’s important not to think you have to chose between “Imperative Programming and Functional Programming” or “Declarative Programming and Object-Oriented Programming”, because it’s like comparing apples and oranges. Put Declarative/Imperative in a box, put the rest in another box.
Wrapping Up
If you’ve liked this article feel free to give claps, leave a comment and suggest enhancements. I hope this will serve you well on your JS journey, because you cannot go far without having to deal with this.
