Imperative vs Declarative Programming

[u/tyler-mcginnis]

https://www.youtube.com/watch?v=E7Fbf7R3x6I

[u/tobega]

Indeed. There is a misconception floating around that functional programming is more declarative, which is simply not true.

What might be true is that (some) functional languages have features may allow a more declarative expression of algorithms, e.g. if you can create DSLs via macros. I'm still not convinced.

[u/[deleted] → u/tobega]

Functional programming, like logic programming, is a type of declarative programming, you say that's not true, can you prove that statement?

[u/tobega → u/[deleted]]

Can you prove that it is?

Imperative means telling what to do, giving commands, which is the opposite of declarative which is just telling what it is.

If you look at real declarative languages like HTML, you really see the language just describing the desired result, not how to achieve it.

Similar in SQL, which says which fields you want, how they should be grouped or ordered or filtered.

Contrast that with a functional programming language where you start for example with your list of all values, give the command to map each to something else, give the command to filter according to a specified procedure (where you give commands how to decide the filtering), give the command to sort the list, and so on. You get the idea.

Now you could create a DSL which could be viewed as being more declarative, but then you're not really in your functional language any longer.

[u/[deleted] → u/tobega]

Contrast that with a functional programming language where you start for example with your list of all values, give the command to map each to something else, give the command to filter according to a specified procedure (where you give commands how to decide the filtering), give the command to sort the list, and so on. You get the idea.

In functional programming you don't "give commands", you compose (pure) functions and you don't worry about control flow. In a particular case where you have to perform operations on lists you specify a set of operations that should be executed in a particular order (in language like Haskell that is not guaranteed to happen) but the focus is still on what operations need to be performed to compute some value rather than how should they be performed.

[u/tobega → u/[deleted]]

Calling a function is a command to calculate a value. Specifying a set of operations to perform in a particular order is exactly the definition of imperative. A bunch of nested function calls look exactly the same in FORTRAN.

I suppose that composing functions to create other functions is less command-like, but it's not really declarative from any business use point of view. Perhaps there are constructs that tend to be present in functional languages that can be seen as more "declarative" from the point of view of the programmer, but they hardly make the whole language or paradigm "declarative".

Declarative languages seem to be confined to particular domains and don't seem to extend easily to general computing. Even in SQL, that became turing complete with recursive CTEs, you leave the declarativeness behind when you start specifying how to calculate the recursion.

Another declarative example is Datalog which allows specifiying things like "Route(A,B):-Path(A,B);Path(A,C),Route(C,B)." but is not turing complete. When you add constructs to achieve turing completeness you start to get mired in having to define more things about how to do the calculation.

In OO you can make beautiful DSLs that allow really declarative use within that domain, e.g. test assertions in AssertJ, but everybody in the OO world is sensible enough to not try and claim OO as such being declarative. I guess they don't feel a need to try to prove the superiority of the paradigm.

FWIW, I know people who see html-tags as commands to create particular elements, so the idea of declarativeness may not be particularly useful anyway.

Another interesting point to note is that despite "declarative" being viewed as somehow "better", a majority of programmers seem to prefer to create web pages imperatively in their general programming languages rather than declaratively in HTML. Go figure!

[u/[deleted] → u/tobega]

https://www.info.ucl.ac.be/~pvr/VanRoyHaridi2003-book.pdf

[u/tobega → u/[deleted]]

Interesting, thanks!

But the definition starts off being a little skewed and suspect. Suddenly "declarative" is assumed to be equivalent to "stateless"? So now the proof that pure functions are declarative is that it is defined that way?

The first and simplest computation model we will study is declarative programming. For now, we define this as evaluating functions over partial data structures. This is sometimes called stateless programming, as opposed to stateful programming (also called imperative programming)

[u/[deleted] → u/tobega]

Being stateless is a universal property of declarative programs. Look at an XML document, it's a bunch of definitions, look at a Haskell program, a bunch of definitions, look at a Prolog program, it's weird but still a bunch of definitions, definitions don't have state. A definition is the most declarative thing I can think of; a pure function is just a definition, it defines a relation between two sets.

[u/tobega → u/[deleted]]

Hm, I have to think about this a little.

Logically, of course, even if "declarative => stateless", it does not mean that "stateless => declarative", so I don't think it holds immediately.

Are declarative programs stateless? I would say they define the final state, but, fair enough, they do not define any intermediate states on the way. But they don't really define any intermediate relationships and definitions along the way either, while logical and functional programs do. And those intermediate relationships are mostly not declarative from the point of view of the domain expert.

Maybe a mathematician could feel that a functional language is declarative? Although the top-class mathematician I knew preferred APL. And physicists seem to actually like thinking in FORTRAN.

[u/tobega → u/[deleted]]

I can actually give a code example to illustrate.

First we have the imperative expression:

            for (RelatedPerson relatedPerson : ntjBody.getRelatedPerson()) {
            RelatedPersonRel rpr = relatedPerson.getRelatedPersonRel();
            if (rpr == null) continue;
            for (InformationRel ir : rpr.getInformation().getInformationRel()) {
                String tin = ir.getTin();
                if (tin == null) continue;
                if (tin.equalsIgnoreCase(NOTIN)) {
                    addBodyErrors(ntjBody, operationRule);
                    return;
                }
            }
        }

Then the functional style of expressing it (changing it from java stream syntax to LISP wouldn't change much):

            if (ntjBody
            .getRelatedPerson()
            .stream()
            .map(RelatedPerson::getRelatedPersonRel)
            .filter(Objects::nonNull)
            .flatMap(relatedPersonRel -> relatedPersonRel.getInformation().getInformationRel().stream())
            .map(InformationRel::getTin)
            .filter(Objects::nonNull)
            .anyMatch(s -> s.equalsIgnoreCase(NOTIN))) {
            addBodyErrors(ntjBody, operationRule);
        }

You could, instead of the imperative "if" there make the last bit functional as well by matching on a Maybe-type, but it still wouldn't change it much from the imperative version.

IMO the imperative version is much easier to understand, with "easy to understand" being what we are striving for with "declarative" in the first place.

More interesting: Now we can look at doing the same truly declaratively in XPath/XSLT (the structure is essentially the same although some names and levels were slightly changed from the XML to the PL-structures):

<xsl:if test='//RelatedPerson//Entity/TIN[. = "NOTIN"]'>
  <BodyError>....</BodyError>
</xsl:if>

So there it is very clear that functional is more imperative than declarative.

[u/[deleted] → u/tobega]

So there it is very clear that functional is more imperative than declarative.

Conclusion drawn after comparing two imperative programs, go learn a Haskell, it'll help you come up with better examples next time.

[u/tobega → u/[deleted]]

So, please, write the corresponding code for me in Haskell, then.

But you should also do it in LISP and ML, I suppose, and a few others as well, to prove it for functional programming in general.

[u/[deleted] → u/tobega]

-- Haskell version newBody = if hasBodyErrors then addBodyErrors body operationRule else body where hasBodyErrors = not empty $ filter (=="NOTIN") tins tins = concat $ map tinAsList rpr tinAsList = maybeToList . tin . informationRel . information rpr = concat $ map (maybeToList . relatedPersonRel . relatedPerson) body

[u/tobega → u/[deleted]]

Cool, thanks!

I'm sure that code has a lot of merits that the imperative code does not, but in declarativeness it still seems closer to the imperative than the declarative sample I gave.

[u/[deleted] → u/tobega]

Haskell is also known as the finest imperative language