Whether pro­gram­ming an app, IoT software or a computer game – de­vel­op­ers have to make a fun­da­men­tal 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­men­tal pro­gram­ming paradigms: de­clar­a­tive pro­gram­ming and im­per­a­tive pro­gram­ming.

What is de­clar­a­tive pro­gram­ming?

There is no one specific de­f­i­n­i­tion of the paradigm, but all de­f­i­n­i­tions agree on one thing: A char­ac­ter­is­tic feature of de­clar­a­tive 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­a­tive pro­gram­ming, the solution path to reach the goal is de­ter­mined au­to­mat­i­cal­ly. This works well, provided the spec­i­fi­ca­tions of the final state are clearly defined and an ap­pro­pri­ate im­ple­men­ta­tion procedure exists. If both of these con­di­tions are met, de­clar­a­tive pro­gram­ming is very efficient.

Since de­clar­a­tive pro­gram­ming does not specif­i­cal­ly describe the “how” but works at a very high level of ab­strac­tion, the pro­gram­ming paradigm also leaves room for op­ti­miza­tion. If a better im­ple­men­ta­tion procedure is developed, the in­te­grat­ed 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­a­tive pro­gram­ming languages are:

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

The different de­clar­a­tive 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­aries are fre­quent­ly blurred and elements of both im­per­a­tive pro­gram­ming – with its sub-types pro­ce­dur­al, modular, and struc­tured pro­gram­ming – and de­clar­a­tive pro­gram­ming are used to solve problems.

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

Im­per­a­tive vs de­clar­a­tive pro­gram­ming

The im­per­a­tive pro­gram­ming paradigm (command-based paradigm) is the older of the two basic paradigms. Unlike in de­clar­a­tive 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­a­tive 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­a­tive pro­gram­ming provides in­struc­tions for assembly, de­clar­a­tive pro­gram­ming provides a picture of the finished piece of furniture as a template.

Instead of leaving the “how” of im­ple­men­ta­tion open with functions, in im­per­a­tive 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­a­tive style.

De­clar­a­tive pro­gram­ming example

One of the strengths of de­clar­a­tive pro­gram­ming is its ability to describe problems more briefly and suc­cinct­ly than im­per­a­tive 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­a­tive pro­gram­ming – as the example shows – while the im­per­a­tive method requires five lines.

Im­per­a­tive pro­gram­ming 

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

De­clar­a­tive pro­gram­ming

$firstnames = array_values($participantlist);

Ad­van­tages and dis­ad­van­tages of de­clar­a­tive pro­gram­ming languages

These days, the de­clar­a­tive 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­a­tive code is char­ac­ter­ized by a high level of ab­strac­tion. This enables de­vel­op­ers to represent complex programs in a com­pressed form. But the more so­phis­ti­cat­ed the ap­pli­ca­tion, the greater the danger that the code becomes so con­vo­lut­ed that it can only be read by the developer who orig­i­nal­ly wrote it. For companies that want to be able to maintain and develop ap­pli­ca­tions without having to rely on a single person’s knowledge, this presents a challenge. External de­vel­op­ers have to carefully read and work out the de­clar­a­tive code until they un­der­stand the structure and have solved any problems.

However, the level of ab­strac­tion in de­clar­a­tive pro­gram­ming also offers ad­van­tages. Because im­ple­men­ta­tion is clearly de­lin­eat­ed from the system using an algorithm, main­te­nance can be performed in­de­pen­dent­ly of ap­pli­ca­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­ti­miza­tion is easier because the algorithm used allows new methods to be in­te­grat­ed. One dis­ad­van­tage of algorithm use is that this kind of formulaic solution is often in­suf­fi­cient­ly equipped to deal with specific char­ac­ter­is­tics of in­di­vid­ual ap­pli­ca­tions.

Not so much a dis­ad­van­tage as a challenge is the con­cep­tu­al model of de­clar­a­tive 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­vel­op­ers 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­a­tive approach can cap­i­tal­ize 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­mate­ly, specific pro­gram­ming of the im­ple­men­ta­tion can take place later. The de­clar­a­tive style is thus well suited for pro­to­typ­ing in agile software de­vel­op­ment.

Ad­van­tages Dis­ad­van­tages
Short, efficient code Sometimes hard to un­der­stand for external people
Can be im­ple­ment­ed using methods not yet known at the time of pro­gram­ming Based on an un­fa­mil­iar con­cep­tu­al model for people (solution state)
Easy op­ti­miza­tion as im­ple­men­ta­tion is con­trolled by an algorithm Hard to take char­ac­ter­is­tics of in­di­vid­ual ap­pli­ca­tions into account during pro­gram­ming
Main­te­nance possible in­de­pen­dent of ap­pli­ca­tion de­vel­op­ment  

In practice, mixed forms of the paradigms are often used these days, with de­clar­a­tive pro­gram­ming languages being sup­ple­ment­ed with im­per­a­tive methods. However, this increases sus­cep­ti­bil­i­ty to errors and can impair the leg­i­bil­i­ty of the code.

Go to Main Menu