Is It Imperative to Be Declarative?

Sigh. Declarative condition expressions are not control flow, they’re part of the definition. They are <i>part</i> of “what” and you could not define anything meaningful without them. The mistake is treating:<p><pre><code> if condition: a else: b </code></pre> As equivalent to:<p><pre><code> if condition: do a else: do b </code></pre> They might seem very similar, but they’re wildly different if you actually have the constraint. There <i>is</i> an implicit “do” somewhere in any program that has IO, but having it mixed in with a declarative program makes no sense and can’t make sense.<p>In the SQL example, nothing <i>happens</i> if you reach the conditional and exit immediately. In the imperative example you have no way of knowing what happened without inspecting the resulting state, or the code that produced it.

This article doesn&#x27;t really get at the core of the distinction between tools like Ansible, chef, terraform and pulumi&#x2F;AWS CDK. There are two languages being discussed here:<p>- the language the programmer writes in<p>- the language that specifies the desired state of the infra.<p>You want the language you&#x27;re writing to be a <i>good</i> language (ie, a language you are productive in). It&#x27;s very helpful for the language the config is specified in to be a declarative manifest. That doesn&#x27;t mean you as a programmer have to write that manifest language directly.<p>Pulumi and CDK are libraries that allow imperative languages to generate a declarative manifest.<p>Terraform is a (very hamstrung) declarative language that is also a declarative description of the desired infrastructure state. It is hard to use because the language is bad. But the language is bad for no reason because it confuses the very desirable property that you want a declarative config with the totally undesirable property that you generate that config with a crippled declarative DSL.<p>Ansible shows another side of this: it&#x27;s a crippled declarative DSL that executes an imperative set of instructions to get the infrastructure into the desired state. The best you can say about the yaml straightjacket is that it causes you to organize your code with some structure, kinda like MVC web frameworks. But yaml&#x27;s declarative nature doesn&#x27;t impart any magic by itself. If you write a step that isn&#x27;t idempotent, it just isn&#x27;t idempotent.<p>If you find yourself wanting to add templates, and loops, and references etc to yaml: this is a smell that you should not be writing yaml. You should use a real programming language to generate yaml. That&#x27;s essentially what Pulumi and CDK are doing. You can think of your real programming language (python or typescript or whatever) as a macro language that outputs the declarative config.<p>(For completeness, chef&#x2F;bash deploy scripts are imperative languages that generate imperative commands to change the infra. Needless to say, this results in a mess usually)

Echoing the article, declarative is a degree and almost all if not all DSL&#x27;s do not achieve declarative purity. The best places for a declarative DSL are for domains which are very elegant and well-studied, such as relational databases.<p>Thus I generally don&#x27;t pay attention to claims about declarative programming — it is rarely actually attempted despite the frequency of advertisement. The domain which Pulumi &#x2F; Terraform targets is most definitely too messy to attempt a pure declarative DSL.

&gt; For various reasons, Terraform was ditched in favour of a python-based boto3 solution, and one of those reasons was that the restrictions of a more declarative language produced more friction than the benefits gained.<p>I feel the same about CMake. It&#x27;s horrendous and everything would be much simpler if you could use the full power of an imperative programming language. Conan on the other hand is Python-based and essentially a framework (though for a different purpose). With a nice set of built-in functions and a clean interface design, I believe that using a full programming language gives you many of the advantages of declarative languages without the oddities and an easy way to drop down to a lower level.

Here&#x27;s a definition of &quot;declarative program&quot; I would start from, (trying to come up with a better definition)<p>Declarative is when the interpretation or execution of a declaration in a program does not depend on the order in which you execute those declarations.<p>Say you have 10 pure functions. The program --its interpretation-- is the same no matter how those functions are ordered in your source-code . The functions can depend on each other but no matter the order in which you call them the results are the same.<p>But if those functions have side-effects, then the order in which you call them can have an effect on the end-result. It can cause an error if some initialization is not done before it is needed. That is not declarative programming then.

AFAIK there is no single generally accepted definition, what does it mean for a language to be declarative.<p>Some people believe that pure functional languages are declarative because of the analogy with mathematics — computations are determined purely by the statement structure, not by the ordering of the statements.<p>Some people (including me) have higher requirements — the declarative programming language should never tell what to do, should only define the problem without providing an algorithm to solve it. According to this definition, pure functional languages are far from declarative as much as the procedural languages. The only pure programming languages here (AFAIK) are some variants of logic programming (Answer Set Programming, Problog, ...), Constraint Programming (MiniZinc, Essence, ...), PDDL, some configuration languages (not all of them), etc. There is nothing wrong in having conditionals&#x2F;loops in the declarative language, as long as they are used to define the problem, not the algorithm to solve it.

I think the article dances around the real issue when it comes to the declarative vs imperative debate. The discussion should always take into consideration the complexity of the system, and its dynamic nature. Systems tend to grow in complexity over time and the declarative constructs that were once enough to describe the state of the system start to require ever increasing complex hacks that resemble imperative code. At that moment the declarative interface for the system should be redesigned, with the new complexity moving into the imperative core, once again making the declarative interface&#x2F;shell be congruent and simple.<p>This process will probably never end, as we build more and more complex systems we will find new abstractions that better fit at modeling the state of the systems, and we have to go through that process of redefining the declarative models on an ongoing basis.<p>If you look at the Kubernetes world, the same pattern played out. You have a declarative layer that is becoming ever more complex and hard to manage using tools like Helm, but then there is also a trend of encoding imperative operational knowledge in new frameworks and operators, that expose a much simpler PaaS declarative layer to users.

I wanted to be capable of bringing up an entire environment with one command using an orchestration of Kubernetes, Terraform, Ansible, Chef and Packer.<p>I wrote <a href="https:&#x2F;&#x2F;devops-pipeline.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;devops-pipeline.com&#x2F;</a> it toplogically sorts a dot diagram file and executes a Graphviz diagram. In theory your code should produce an entire environment that is ready to use.<p>It is infrastructure as code and pipeline&#x27;s as code. It also runs parts of the diagram that can run in parallel in parallel<p>Creating robust stateful code is an exercise in frustration. Just look at any command line utility that manages state of files or EC2 instances. If you run something and it fails then the files or infrastructure Is in an unknown state. This is the problem that both declarative and imperative tools have

The article asserts that anything that includes a conditional must be imperative because it dictates control flow. Under that view, the definition of the Fibonacci sequence would be imperative.<p><pre><code> F(n) = 1 (n = 1) F(n) = 1 (n = 2) F(n) = F(n - 1) + F(n - 2) (n &gt; 2) </code></pre> But the above definition says nothing about how you should calculate the value of F(n). As a matter of fact, math tells us that the definition of F(n) can be converted to a formula that doesn&#x27;t include conditionals. In other words, the conditional in the original definition of F(n) has no direct relationship to the actual control flow of programs that calculate F(n).<p>It follows that F(n) is defined declaratively, invalidating the claim that declarative expressions can&#x27;t contain conditionals.

This post assumes that there is consensus around a formal definition of being <i>declarative</i>. This is hardly the case as highlighted by Robert Harper, an academic recognized for his work in the field of programming formalization , in his essay &quot;What, If Anything, Is A Declarative Language?&quot; [1].<p>[1] - <a href="https:&#x2F;&#x2F;existentialtype.wordpress.com&#x2F;2013&#x2F;07&#x2F;18&#x2F;what-if-anything-is-a-declarative-language&#x2F;" rel="nofollow">https:&#x2F;&#x2F;existentialtype.wordpress.com&#x2F;2013&#x2F;07&#x2F;18&#x2F;what-if-any...</a>

&gt; &gt; “In computer science, control flow (or flow of control) is the order in which individual statements, instructions or function calls of an imperative program are executed or evaluated. Within an imperative programming language, a control flow statement is a statement that results in a choice being made as to which of two or more paths to follow.”<p>&gt; This can be reduced to:<p>&gt; &gt; “Imperative programs make a choice about what code is to be run.”<p>No. You left out the part about order, which is the most important part.

proposition: declarative computation is one that is compiled or interpreted into something with lower control flow. consider lisp: your DSL can have control flow if the macros process the control flow forms (if, lambda) into some lower thing (that lower thing often being lisp itself but after all macroexpansion). I.e. reactive DSL is declarative with respect to when recomputation happens and when memoization happens, the programmer does not specify these aspects they are implied. however the same DSL can still be imperative with respect to effect sequencing.<p>another is programming with DAGs, the DAG captures control flow schematics as a value, abstracting away the actual evaluation rules (maybe the DAG is meant to be async, or reactive, or distributed). The DAG is declarative with respect to the abstracted evaluation rules, yet if there are effects in DAG nodes, we are not declarative with respect to those. We are however declarative with respect to how effects with a lifecycle are maintained and garbage collected, as that behavior is given by certain runtimes for the DAG.

TIL that Prolog has loops. I can&#x27;t imagine how you would use them, though.

I think this strikes at such a great line of reasoning: declarative vs imperative is the wrong abstraction.<p>The thing I actually care about is: can I use a programming language or not?

When a problem can be solved mindlessly - with a repeatable set of steps no matter the situation - imperative&#x2F;declarative programming makes sense.<p>Most real world situations are unique and require unique solutions. That&#x27;s where AI really shines. You just describe your target, attempt to solve the problem, and pay attention to how far off you were from your target. The learning happens naturally.<p>Neural networks are too complex - sometimes billions of variables - to decide what each neuron should do. We as a species have evolved to develop brains that are extremely adaptable. AI mimics our own natural learning process. And it&#x27;s proven to be far more effective at solving unique problems.