Is declarative programming just imperative programming 'under the hood'?

Question

From my understanding, in declarative programming, programmer only need to define the end result, but not how to compute it. But for execute that said function, the function must be pre-defined by the language, that instruct the machine to compute, step by step, for user to use in the first place - hence it implementation is imperative.

So is declarative programming just imperative programming 'under the hood'? If so then how to differentiate them two?

And if I happen to write a very complex program (or any program at all), at some point I will have to give implicitly step-by-step instruction, is there any way I can get around this and use the declarative approach instead?

Answer 1

Differences

So is declarative programming just imperative programming 'under the hood'? If so then how to differentiate them two?

Two of the major differences between declarative and imperative programming are mutation and eager evaluation.

Mutation

If you are writing some code, just ask yourself: "After I define variable x, am I able to reassign it to something else?" If the answer is: "No, not at all", then you are probably working in a declarative language.

Eager Evaluation

If you write an expression, ask yourself: "Can I enumerate exactly when and where this expression will be evaluated, even with respect to other expressions?" If the answer is "No, the language decides that because the order does not change the output", then you are probably using a declarative language.

Limits

And if I happen to write a very complex program (or any program at all), at some point I will have to give implicitly step-by-step instruction, is there any way I can get around this and use the declarative approach instead?

Well, a more precise way to say this is that every computation produces an output that depends upon its inputs (though a write-only program may have the empty set as its input). And at the minimum, the programmer must specify what parts of the output depend on which parts of the input. You can't properly specify a computation without providing this information. What you may or may not need to do, however, is specify the order in which those evaluations take place.

Let's consider a mostly declarative language that hopefully a lot of people are familiar with: SQL. Now, UPDATE and DELETE queries make it imperative, so let's just consider the subset using SELECT and INSERT. You can perform some fairly complex calculations with just these primitives. And you can perform them on very large tables. If they are indexed properly, something somewhat magical happens: when you run the query, you get the result in a reasonable amount of time, even though you didn't specify the manner in which the tables should be joined.

You can somewhat force a join order by using sub-select statements, but this would almost never be considered best practice. In general, it is enough to tell the query engine which tables contain the rows of interest, and let it decide how to join those tables to produce the desired result. At no point are you ever required to direct the query engine to join tables in a particular order, or to use one index or another.

At the same time, you can investigate whether the query engine is doing a good job by running EXPLAIN PLAN. This lifts the hood so you can see the "imperative engine running inside". But if you follow best practices for creating indices and regularly updating statistics, then this is not necessary. It doesn't matter whether you are querying 10 rows from a table with 1000 or querying tens of thousands of rows from a join of dozens of tables. The entire goal of SQL is to remove the need for the programmer to tell the query engine how to do its job.

A similar process is at work in other declarative languages.

Answer 2

At a lower level, every(?) CPU in current use is essentially imperative so yes, everything has to be imperative at some level.

However, to some extent that's not really important: everything is an abstraction and the real question is "is this abstraction useful?", and we certainly find that declarative programming is a useful abstraction in many circumstances. Sure, if you're actually implementing a declarative programming language you may have to write some imperative code, but that's the same as if you're implementing an imperative language at some point you have to write some assembly. And if you're implementing a CPU, you have at some point to deal with transistors etc.

Answer 3

To expand already existing answers, there are languages like VHDL which are mainly for writing declarative code and they can produce truly declarative output in the form of hardware, which executes "everything at once", so the order of execution is irrelevant.

On the other hand, there exists high level synthesis which takes imperative language like C and then the final output is hardware, so the imperative programming languages can be "declarative under the hood".

So the answer is that imperative/declarative code can be imperative/declarative under the hood. You have to differentiate the languages by their features. You can tell language is declarative mostly by the fact you can't reassign variables or it doesn't make sense and that it doesn't have loops in normal sense.

Answer 4

All programming languages are essentially abstractions for humans to express problems, and automate the solution to those problems. The difference between declarative and imperative is in how they allow and encourage programmers to express their problems, and as a consequence how the solutions to those problems are automated.

The existence of a lower-level implementation written in a different abstraction is irrelevant, except to the extent that practical implementations do not form perfect abstractions, so "leak" details all the way down to electrical interactions.

In an imperative language, the abstraction provided by the language is that of a sequence of actions, specified in chronological order. The language definition will generally guarantee that the observed behaviour of the program is consistent with that order of operations. At a lower level, an optimising compiler might rearrange some of those operations where it can prove it will not change the observed result; and a processor may evaluate branches in advance and discard the result if that path is not taken. Those abstractions may leak, leading to bugs and vulnerabilities, but the primary abstraction of the language is that things happen in order.

In a declarative language, the abstraction provided is that of a set of declarations, which may use source code order to define dependencies and other relationships, but are not laid out in a strict chronological order. The compiler or execution engine has much more freedom to rearrange the order of operations, or choose between multiple implementations of a particular operation, to achieve the requested result. Generally, such languages are modelled as having immutable data structures and side-effect free operations - the program is more closely related to a mathematical proof than a recipe. Again, the abstraction might leak, and the programmer may need to force a particular order of operations, but the primary abstraction of the language is that statements are re-orderable.

As with most categorisations, these are not black and white: a language can incorporate features of both styles, and be "more declarative" or "more imperative". A C program written in a Functional Programming style might allow a compiler to make more assumptions than one written in a traditional Procedural style, but most C programs contain a large amount of code that is imperative - i.e. reasoned about as an ordered sequence of operations.

Answer 5

A programming language is only a mean to express some abstract computational solution, independently of how the language abstractions will be implemented.

So no, it's not just imperative under the hood. The language implementation may transform the higher language in imperative code. Or it may apply imperative code to deal with the non imperative stuff (e.g. term rewriting, unification, etc...). But you don't have to care, you just have to select the most suitable language for the kind of problems you're trying to solve.

It's not because every language ends up being executed in machine code, that one could say every programming language is only machine code under the hood.

Answer 6

Is declarative programming just imperative programming 'under the hood'? If so then how to differentiate them two?

Yes, declarative programming is imperative programming 'under the hood'. In fact, all declarative programming languages are implemented in another imperative programming language (directly or indirectly).

But to differentiate between them you should not look 'under the hood'. You should look at the controls, from the point of view of the driver. Does it have a steering wheel? If yes, then it's a normal car. Do you enter the destination in a map and then just wait to get there? Then it's a fully autonomous car.

It's the same way with programming languages: do you specify each step that needs to be done? Then it's an imperative language. Do you just specify the characteristics of the output, without specifying how to compute the results? Then it's a declarative language.

Answer 7

I'd argue that the difference between imperative and declarative is simply the presence of an optimising compiler.

I'd also argue that nowadays the distinction isn't a useful one.

The classic example given of a declarative language is SQL, and that's because once upon a time its optimising capabilities and execution engine had no recognisable analogy in languages deemed imperative.

But that kind of talk is old hat. Nowadays, powerful optimising compilers are completely ordinary amongst basically all languages (certainly commercial compilers for mainstream languages), as are various kinds of execution engines which supervise and alter their own workings dynamically to improve efficiency.