Why is imperative programming so complex

Java blog for programmers

In some way, a developer needs to describe his problem in program form in order for the computer to ultimately execute it. There are different forms of description here, which we call the programming paradigm. So far we've always dealt with imperative programming, where instructions are central. In German we have the imperative, that is the command form, which can be compared very well with the programming style, because in both cases these are instructions of the type “do this, do that”. These "commands" with variables, case distinctions, jumps describe the program and the solution.

Although imperative programming is technically the oldest, it is not the only way to describe programs; there is also declarative programming, which does not describe the “how” for problem solving, but rather the “what”, ie what is actually required without getting entangled in precise processes. At first glance this sounds abstract, but for anyone who has ever done

A selection as in * .html used on the command line,

Written a database query with SQL,

An XML selection made with XQuery,

A build script formulated with Ant or make,

· Has described an XML transformation with XSLT, will know the principle.

Let's stick with SQL for a moment, just to make one point clear. Of course, in the end the processing of the tables and evaluations of the results by the CPU is purely imperative, but it is about the program description on a higher level of abstraction. Declarative programs are usually much shorter, which means that additional advantages such as easier expandability and comprehensibility come into play. Since declarative programs often have a mathematical background, it is easier to formally prove the correctness of the descriptions.

Declarative programming is a programming style, and a declarative description needs a kind of "runtime environment" because SQL, for example, cannot directly execute a CPU. But instead of only dealing with special use cases such as database or XML queries, typical algorithms can also be formulated declaratively, with functional programming. This means that imperative programs and functional programs are equally powerful in their possibilities.

Functional programming and functional programming languages

In functional programming, the focus is on functions and ideally stateless behavior in which recursion is used a lot. A typical example is the calculation of the factorial. It is n! = 1 · 2 · 3 ·… · n, and with loops and variables, the imperative way, it looks like this:

public static int factorial (int n) {

int result = 1;

for (int i = 1; i <= n; i ++)

result * = i;

return result;


The many assignments and the distinction between cases can be clearly seen through the loop; the typical indicators for imperative programs. With the recursive variant it is completely different, there are no assignments in the program and the spelling is reminiscent of the mathematical definition:

public static int factorial (int n) {

return n == 0? 1: n * factorial (n - 1);


With functional programming we have a real alternative to imperative programming. The only question is: which programming language can be used to write functional programs? Basically with any high level programming language! Functional programming is a programming style, and Java supports functional programming, as we can see from the example with the faculty. Since that's basically all, the question arises why functional programming has such a difficult time and is feared by developers. There are several reasons for this:

Readability. At the beginning of the functional programming languages ​​there is historically LISP from 1958, a very flexible but difficult to read programming language. Our faculty looks like this in LISP:

(defun factorial (n) (if (= n 1) 1 (* n (factorial (- n 1)))))

All the brackets make the programs difficult to read and the expressions are in the prefix notation - n 1 instead of the usual infix notation n - 1. It is different with other functional programming languages, but this leads to a certain prejudice that all functional Programming languages ​​are difficult to read.

Performance and memory consumption. Without clever optimizations on the part of the compiler and the runtime environment, recursive calls in particular lead to bulging stacks and poor runtime.

Purely functional. There are functional programming languages ​​that are referred to as "pure" or "pure" and do not allow any status changes. The development of input / output operations or simple random numbers is a big act that is no longer comprehensible for normal developers. The concepts are complicated, but luckily most functional languages ​​are not that pure and allow state changes, only programmers use them as infrequently as necessary.

Functional with Java. When it comes to working with functions only, developers quickly get to the point that functions pass other functions as arguments or return functions. Something like this can only be written in Java in the traditional syntax very laboriously, so that everything becomes so illegible that the entire advantage of the compact declarative notation is lost.

From today's perspective, a combination of both concepts is future-oriented. With the notation of lambda expressions introduced in Java 8, functional programs are compact and relatively easy to read and the JVM has good optimization possibilities. Java enables both programming paradigms and developers can choose whichever way is best for solving problems. Of course, this ambiguity also creates problems, because whenever there are several solutions, disputes arise over the best of the variants - and here from developer to developer a contrary opinion can prevail. Functional programming has undoubted advantages and we want to take a closer look at that.

similar posts

Posted in island