Whether pro­gram­ming an app, IoT software or a computer game – de­velopers have to make a fun­da­ment­al decision before they write their first line of code: What pro­gram­ming language do they want to use? A variety of languages is available, but all of them can be assigned to two fun­da­ment­al pro­gram­ming paradigms: de­clar­at­ive pro­gram­ming and im­per­at­ive pro­gram­ming.

What is de­clar­at­ive pro­gram­ming?

There is no one specific defin­i­tion of the paradigm, but all defin­i­tions agree on one thing: A char­ac­ter­ist­ic feature of de­clar­at­ive pro­gram­ming languages is that they always describe the desired end result rather than outlining all the in­ter­me­di­ate work steps. In de­clar­at­ive pro­gram­ming, the solution path to reach the goal is de­term­ined auto­mat­ic­ally. This works well, provided the spe­cific­a­tions of the final state are clearly defined and an ap­pro­pri­ate im­ple­ment­a­tion procedure exists. If both of these con­di­tions are met, de­clar­at­ive pro­gram­ming is very efficient.

Since de­clar­at­ive pro­gram­ming does not spe­cific­ally describe the “how” but works at a very high level of ab­strac­tion, the pro­gram­ming paradigm also leaves room for op­tim­isa­tion. If a better im­ple­ment­a­tion procedure is developed, the in­teg­rated algorithm can identify and use it. This makes the paradigm fu­ture­proof. The procedure for how the result is to be achieved does not have to be set in stone when writing the code.

The best-known de­clar­at­ive pro­gram­ming languages are:

  • Prolog
  • Lisp
  • Haskell
  • Miranda
  • Erlang
  • SQL (in the broadest sense)

The different de­clar­at­ive pro­gram­ming languages can, in turn, be divided into two paradigms: func­tion­al pro­gram­ming languages and logic pro­gram­ming languages.

However, in practice, the bound­ar­ies are fre­quently blurred and elements of both im­per­at­ive pro­gram­ming – with its sub-types pro­ced­ur­al, modular, and struc­tured pro­gram­ming – and de­clar­at­ive pro­gram­ming are used to solve problems.

Image: Overview of the systematisation of imperative and declarative programming
Pro­gram­ming languages can be assigned to two fun­da­ment­al pro­gram­ming paradigms, which in turn have their own pro­gram­ming styles.

Im­per­at­ive vs de­clar­at­ive pro­gram­ming

The im­per­at­ive pro­gram­ming paradigm (command-based paradigm) is the older of the two basic paradigms. Unlike in de­clar­at­ive pro­gram­ming, in this case, the developer specifies in the source code precisely what the computer should do, step by step, to achieve the result. The focus is on the “how” of the solution path. For example, this approach can be found in Java, Pascal, and C. By contrast, in de­clar­at­ive pro­gram­ming the “what” of the solution is described directly.

As an example, let’s apply the idea to furniture assembly: While im­per­at­ive pro­gram­ming provides in­struc­tions for assembly, de­clar­at­ive pro­gram­ming provides a picture of the finished piece of furniture as a template.

Instead of leaving the “how” of im­ple­ment­a­tion open with functions, in im­per­at­ive pro­gram­ming there are variables, which are changed at runtime. This makes the code longer but also more un­der­stand­able than the truncated and very abstract form of the de­clar­at­ive style.

De­clar­at­ive pro­gram­ming example

One of the strengths of de­clar­at­ive pro­gram­ming is its ability to describe problems more briefly and suc­cinctly than im­per­at­ive languages.

If we want to output a list of first names, in PHP this can be described with just one line of code using de­clar­at­ive pro­gram­ming – as the example shows – while the im­per­at­ive method requires five lines.

Im­per­at­ive pro­gram­ming 

$participantlist = [1 => 'Peter', 2 => 'Henry', 3 => 'Sarah'];
$firstnames= [];
foreach ($participantlist as $id => $name) {
    $firstnames[] = $name;
}

De­clar­at­ive pro­gram­ming

$firstnames = array_values($participantlist);

Ad­vant­ages and dis­ad­vant­ages of de­clar­at­ive pro­gram­ming languages

These days, the de­clar­at­ive pro­gram­ming style is used in a variety of cases, even if not in its purest form. However, the method is not suitable for all uses.

De­clar­at­ive code is char­ac­ter­ised by a high level of ab­strac­tion. This enables de­velopers to represent complex programs in a com­pressed form. But the more soph­ist­ic­ated the ap­plic­a­tion, the greater the danger that the code becomes so con­vo­luted that it can only be read by the developer who ori­gin­ally wrote it. For companies that want to be able to maintain and develop ap­plic­a­tions without having to rely on a single person’s knowledge, this presents a challenge. External de­velopers have to carefully read and work out the de­clar­at­ive code until they un­der­stand the structure and have solved any problems.

However, the level of ab­strac­tion in de­clar­at­ive pro­gram­ming also offers ad­vant­ages. Because im­ple­ment­a­tion is clearly de­lin­eated from the system using an algorithm, main­ten­ance can be performed in­de­pend­ently of ap­plic­a­tion de­vel­op­ment. In­ter­rup­tions of day-to-day op­er­a­tions are reduced to a minimum. At the same time, op­tim­isa­tion is easier because the algorithm used allows new methods to be in­teg­rated. One dis­ad­vant­age of algorithm use is that this kind of formulaic solution is often in­suf­fi­ciently equipped to deal with specific char­ac­ter­ist­ics of in­di­vidu­al ap­plic­a­tions.

Not so much a dis­ad­vant­age as a challenge is the con­cep­tu­al model of de­clar­at­ive pro­gram­ming. Thinking in terms of solution states con­tra­dicts natural human thought processes. People tend to think in terms of processes moving towards a goal rather than starting from a goal and working backward. This requires de­velopers to rethink and accustom them­selves to the concept, which can initially slow down problem-solving. However, once the new mindset has been learned, the de­clar­at­ive approach can cap­it­al­ise on its strengths.

Another advantage of de­vel­op­ment starting from the de­scrip­tion of the problem is that teams can outline solution models rapidly. Ul­ti­mately, specific pro­gram­ming of the im­ple­ment­a­tion can take place later. The de­clar­at­ive style is thus well suited for pro­to­typ­ing in agile software de­vel­op­ment.

AdĀ­vantĀ­ages DisĀ­adĀ­vantĀ­ages
Short, efficient code Sometimes hard to unĀ­derĀ­stand for external people
Can be imĀ­pleĀ­menĀ­ted using methods not yet known at the time of proĀ­gramĀ­ming Based on an unĀ­faĀ­milĀ­iĀ­ar conĀ­cepĀ­tuĀ­al model for people (solution state)
Easy opĀ­timĀ­isaĀ­tion as imĀ­pleĀ­mentĀ­aĀ­tion is conĀ­trolled by an algorithm Hard to take charĀ­acĀ­terĀ­istĀ­ics of inĀ­diĀ­viduĀ­al apĀ­plicĀ­aĀ­tions into account during proĀ­gramĀ­ming
MainĀ­tenĀ­ance possible inĀ­deĀ­pendĀ­ent of apĀ­plicĀ­aĀ­tion deĀ­velĀ­opĀ­ment

In practice, mixed forms of the paradigms are often used these days, with de­clar­at­ive pro­gram­ming languages being sup­ple­men­ted with im­per­at­ive methods. However, this increases sus­cept­ib­il­ity to errors and can impair the legib­il­ity of the code.

Go to Main Menu