# If declarative programming is possible at the instruction/action level?

I am considering what the possibilities are with declarative programming. I have a firm understanding of how to use declarative programming in practice, but, short of having examples, I don't know if it's possible to 100% use declarative programming all the way down to the machine code (theoretically).

Standard QA sites like this says stuff like:

it means describing the problem to be solved, but not telling the programming language how to solve it

A typical example is a SQL query which uses a where clause to define the query rather than implementing the query it step-by-step using something like an iterative loop.

An example I am interested in is an even higher level abstraction than a SQL query: defining an HTTP server. You can define the server and all of it's GET handlers (if we just limit it to that for now) in a completely declarative way, as seen by many declarative frameworks. The declarative frameworks that do similar stuff to this are the ones like Terraform or SaltStack that define machine configurations/states. You are basically defining the state the machine should look like, and the system takes your "definition" and makes it happen.

For the HTTP server you can do like in React:

<Route path='/' component={Home}>
<Route path='/terms' component={Terms}>
...
</Route>


This then automagically gets wired up into a listening server for these changes, and renders the components (this API may not be exact, just pseudocoding it ftm).

In fact, there is a lot that can be done declaratively. HTML and CSS together form an animatable graphics display and is completely declarative. You can define servers, machines, parsers (PEG parser generators), graphics... I don't know what else.

That's mainly what my question is, what can be done declaratively. More specifically, what cannot be done in a declarative fashion. The stereotypical example I am thinking of is simply defining a step-by-step sequence of actions of some sort, but in a declarative, non-iterative way. Is it possible?

Here is my attempt.... Say we are describing some automation steps for interactively going through and clicking around a website. Here is the iterative way:

Visit "/"
Click on "Button 1"
Wait "2 seconds"
Click on "Button 2"
For each "Input" in "Fields"
Type into "Input"
Click on "Button 3"
Wait "2 seconds"
...


This is similar to assembly instructions like mov. But can this be done in a declarative way (that is also readable and easy to understand)? Does functional programming offer any insight? Maybe one could show how to do this in a functional programming paradigm, or even a logic (prolog-ish) way, if that would help illuminate how it's done. My attempt at declarative is like this:

Current State should be "/"
Button is not clicked
Button has been clicked
2 seconds have passed
...


Basically, just stating the "states" before and after each step sort of thing. That makes it harder to read, and it feels like you are trying to hack around having to build some iterative code anyways. It's like it has to be iterative. Is that so? Is there any way to make this non-iterative and so it still makes sense?

To me, currently, it seems that you can use declarative programming for like 80-90% of things, but then you inevitably need "parsing" code which will take those declarative statements and interpret them, converting them into some iterative sequence. But what I'm left wondering is, can that 10-20% that seems to have "iteration" as a requirement be instead written declaratively? Can you take that 10-20% remaining iterative code and make that declarative too? If so, how would that look or what is the technique?

Machine code is imperative, not declarative, so if you want your code to execute on a conventional CPU, at some point there needs to be some code that converts the declarative program to imperative style (e.g., a compiler), and at least some of that code needs to be written imperatively (because at least some of it needs to be written in machine code). It can't be turtles all the way down.

AFAIK, the meaning of the term “declarative vs. imperative” changed over time. The original meaning is what you cited, “how vs. what”. This distinction is philosophical, so its meaning varies from person to person. To be honest, after all these years, I failed to understand it, so I will not discuss it here.

A more specific meaning of “imperative” emerged: a programming language is imperative if it has the concept of command and a program written in the language defines the order of commands. For example, in C, commands are called statements, and the implementation is required to execute statements in the order that they are written and even execute subexpressions of an expression in the order that they are written. Hence C is considered imperative. The programming languages Haskell and Prolog (without extra-logical features), according to this definition of “imperative”, are non-imperative, in other words, declarative.

In principle, the question is answered by the Turing Thesis. Since there are Turing-complete declarative languages (both Haskell and Prolog are), declarative languages can do everything that imperative languages can. Even pure lambda calculus, having only 3 syntax constructs, is Turing-complete. Haskell provides a feature for convenient translation of imperative programs into Haskell, the IO monad. The translated program looks almost like an original imperative one.