Why does nobody seem to know what imperative and declarative mean?
leebriggs.co.uk
leebriggs.co.uk
Knowing the difference between imperative and declarative is very important.
But like Terraform can be if you start importing data-sources, Pulumi can get dynamic. Your Pulumi code might have some actions/verbs it does to figure out what to write. You might slip up one day and get a little bit pregnant. Oops I mean get a little bit imperative. In Terraform, these external dependencies are declared, are declarative style, but they carry the risk of imperativeness, in that they don't have idempotency, they don't clearly delineate what is expected: they're commands-as-structures, actions-as-structures, executed via higher level systems.
Pulumi might not be imperative, but there's less clear lines (unlike an explicit Terraform data-source) & it's less clear when you get a little bit imperative.
Here it is, quoted from the middle of the article:
While the operation of checking the value of isMinikube is indeed imperative, the result is still declarative. What does this mean?
Pulumi as a tool is declarative.
It’s the language you’re using to write things that’s imperative, not Pulumi itself.
So let me get this straight, if a tool that uses an imperative language emits a declarative configuration that the tool executes, the original tool is declarative and not imperative.
…because, and this is the core argument here: at the execution step, the commands that are executed, are executed in sequence by the tool without flow control, except that which is internal to the tool itself (eg. check if s3 bucket is present, if so, don’t create it).
So, for example, if I compile source code into a assembly, and then run it… the assembly is executed step by step.
…so, my code is declarative then is it? Since the artifacts emitted by the compile step are a linear sequence of steps with no flow control other than what the compiler emits?
This is just pedantic nonsense.
Look, flat out: if you apply flow control, it is imperative.
It’s completely ridiculous to say that if you generate a declarative configuration in an imperative manner, and execute the declarative configuration, the end-to-end process is declarative.
It’s not. It’s imperative.
No amount of redefining terms is going to change that.
If you want, you could invent something called “declarative infrastructure deployment”, which is where the end user does not manually define imperative code to check the infrastructure state, and relies on the tool to check and resolve the “desired state”. You could also call it “desired state deployments”, or “cool deployments”.
The you could say, sure these tools either are or are not conforming to your definition of this type of tool.
Sure, fine. That’s easy to verify; does the tool expose primitives to express flow control in response to deployed infrastructure state explicitly? It’s a yes / no.
…but, that doesn’t make those tools declarative. They’re just “whatever term you invented here” tools. …but putting “declarative” in the name you invented doesn’t make it declarative.
Pulumi has flow control. It is imperative. QED.
Fundamentally the model is still: this is the state I want, and Pulumi figures out how to make that happen. Just like Terraform. The specification of that state can be static, fill-in-the-blank templated, or make use of imperative logic to build the final data structure. Just like Terraform, albeit one step removed because of the yaml intermediary.
Is it easier to write an imperatively-specified boondoggle of a state because of the direct access to an imperative runtime, sure. But that's against best practice and not what they're advocating here. Hell, I could hide the ternary behind a declarative interface (function) and then what's the difference between the imperative code hidden by my function and the imperative code hidden behind Pulumi's or Terraform's state evaluation and application functions?
I’m saying, this article is about the pedantic definition of what it means to be declarative vs imperative.
…and pedantically, if you’re partially imperative, you’re imperative.
Otherwise, you’re choosing to redefine the terms to suit your convenience.
Which you’re welcome to do too… but you can’t pedantically tell people they don’t know what a term means and redefine it to mean something convenient.
The imperative vs declarative argument has been used to keep Pulumi out of several infra repos I have been responsible for. A ball of horrible Terraform is much better than a ball of terrible Node.js Pulumi.
https://twitter.com/dave_universetf/status/14864638523131330...
Also that rant is just a woeful misunderstanding of well everything, but in particular AWS and k8s. If you do it in Terraform you couldn’t specify the AZs either and instead have to define a VPC config with two subnets. That’s an AWSism not Pulimi.
“I will learn nothing and complain the whole time!” isn’t as damning of a criticism as they think.
In the limit, all config files become a language.
So if you have a so-called "declarative" config file, it eventually becomes a ... ? Language - that's imperative. Every time. Yes, really.
What is the only time this doesn't happen? If the config system ceases to exist.
In this case, you're using imperative languages to generate declarative policies. Things just aren't black and white.
Importantly, it doesn't really matter. We say "Python is interpreted" because the it gives you the UX of an interpreted language. We say "Pulumi is imperative" because it gives you the UX of an imperative language. Under the hood they do their own thing, but unless you're trying to have a really precise conversation it's usually easiest to stick to those terms.
I'd still take issue with that description. There is a massive UX distinction here that isn't under the hood.
Your imperative Pulumi code is at a meta/macro/preprocessor level. That's completely different from writing imperative code that manipulates your servers.
Your code generates declarations. It does not take actions.
Boiling that down to one word is likely not the best way of doing it, but I agree with the author that in this situation the function/output of what you write is more important than how it gets there. The stuff you write doesn't configure servers, it describes servers.
I think it was Plato who asked this question - if I take two pieces of clay and smash them together, which piece grew? You can argue all day about it, and it has some fun implications about identity, but that's philosophy.
The thing about writing "code that outputs a data structure" is that you can voluntarily choose to use no control flow.
The tool takes declarative input, and optionally you can use imperative code to make the job of writing that input easier.
That's very different from a tool that gives you helper functions for writing an imperative core. In that case you're always writing something that's full of control flow, and it's up to you to make sure you get all the state transitions to be consistent with each other.
I didn't see much complaint about imperative vs declarative.
Puppet started popularizing declarative configuration management almost a full decade earlier.
Idea is, you run Terraform to create/modify the infrastructure, and Puppet to configure the software running on that infrastructure.
Imperative: Describe step by step how a global mutable state is manipulated.
Functional: Describe how an immutable value is calculated.
I mean, what practical thing do you think people should do differently?
Besides, we are just arguing about the definition of some words that people can't really agree on their meaning (most people are close to each other, so the words aren't meaningless, but they are still different). Piling-up more of those words isn't a benefit.
So what I get from this is that Pulumi is declarative, but authoring Pulumi is imperative (unless you’re using an declarative language, which afaik Pulumi doesn’t support any).
I’m a pretty pedantic person, so I’d probably make this same argument once I had the knowledge. I don’t see what it changes for a developer though. If I’m writing imperative code then the tool running my IaC might as well be imperative. I guess it’s a cool piece of trivia to know though.
It doesn't make sense to define the attributes of a tool by its artifacts. If we applied that logic across the board then Haskell isn't a purely functional language because it eventually gets compiled to machine code which is imperative.
What matters is the source, not the artifact. In the case of Pulumi you are using imperative languages, so Pulumi is effectively imperative, although it can technically be considered declarative when you consider the Pulumi runtime. If Pulumi had support for a declarative language, then I would consider it a declarative tool.
Declarative is necessary if one is trying to have something maintain a desired state and do what is necessary to move the current state to the desired state.
I wonder if this is why I hear a lot of people say K8S is complex. I mean, it isn’t simple, but it isn’t _that_ complex.
Pulumi has a YAML evaluator, with many of the same limitations of Terraform being imposed.
It’s an important distinction to make because passionate CDK/Terraform/CloudFormation defenders use the dichotomy to dismiss different tools.
No flow control? Declarative.
What is flow control? Typically if/then/else statements.
Importantly, setting a variable with a conditional does not make the language necessarily imperative.
I wonder if a language can be Turing-complete without flow control. My guess is no?
> Flow control? Imperative. > No flow control? Declarative.
I think I'd rather say:
Imperative: Tell the system what to do.
Declarative: Tell the system what you would like to be. The system figures out what to do to get there.
You could well have flow control to say things like "if things are like that, I want things to be such", or "here is a loop building up what I would the state of the system to look like", still without telling the system what to do to get to that state.
> I wonder if a language can be Turing-complete without flow control. My guess is no?
Depends on your definition of "flow control". Untyped lambda calculous is effectively entirely just declaration and application of anonymous functions with only one argument, but it's Turing complete.
You can even try it in any language that has lambdas as first class citizens, e.g. here's a factorial function I wrote in Lambda calculous, but implemented in python:
fac = ((lambda p: p(p)(lambda q: lambda n: ((n(lambda e: lambda e:
lambda a: a)(lambda i: lambda l: i))(lambda d: lambda c: c)
(lambda m: (lambda m: lambda z: m(n(z)))(q(m)))((lambda c: lambda x:
n(lambda g: lambda h: h(g(c)))(lambda u: x)(lambda u: u))))))
(lambda s: lambda q: lambda w: q(s(s)(q))(w)))
Would I call Lambda calculous declarative? Not at all!
Yep. That’s why this is a potentially useful rule of thumb for comparing programming languages, especially ones that skew very far in one direction or the other, but it’s not a rigorous definition of the concepts.
Some incredibly simple algorithms are difficult to explain naturally without it sounding like control flow. How would you describe the absolute value function without saying “if” or “when” or specifying one particular element from a set? Obviously any computer system needs to be able to determine what steps to take depending on specified conditions.
How is this? absolute value is distance a number is from 0.
I get your point, though.
I don't think you even want a conditional when describing the absolute value function on the complex numbers.
I agree, unless something like pattern-matching does not count as control flow. But then isn't a conditional just a basic pattern? Why does it get a pass?
I can’t imagine why not. I think you have to make the distinction between explicit control flow in the syntax, which declarative languages don’t have (according to this rule of thumb), and the notion of a computer choosing to do one thing among several options depending on some condition. Of course any Turing-complete system can do the latter, but that’s totally unrelated to the syntax of the programming language.
Just his example of `x = a ? b : c`, I never saw anybody try to claim code like this makes a language imperative. Instead, I've seen many people calling this logic "functional if".
If you go with his definition, only simple variable declaration is declarative.
(By the way, a very popular definition is that imperative languages have flow, not flow control. AKA, it makes a difference if you go and execute the instructions on a different order. That one is reasonable, but then, why single out non-associativity of operations when there are many other things that no language makes non-associative?)
> At their core, imperative and declarative differ in one major and fundamental way. Imperative has control flow and declarative does not.
The SQL guy sort of made sense I guess maybe.
When you write an SQL query, you're not describing steps to take, you're describing the outcome you want (what rows and fields from which tables and how those tables relate to each other). The query engine then takes that description and figures out how to actually do the query (what indices to use, in what order, how to actually loop/hash/map/scan the tables and indices, etc). This is what EXPLAIN shows you, the actual imperative plan the query engine came up with given the declarative query you gave it.
Another common example would be CSS: It's all about describing the desired result and spatial relationships between elements, then the CSS engine takes those rules and figures out how to actually get those elements to do what you want. Like something as seemingly simple as "float: left" - for the text to wrap around it, the engine has to deal with the image size, position, font and font size, figuring out when to wrap the text, height of the font, which line of text is greater than the image height, etc. The engine does a lot of work figuring out the steps to take to get the result you've described.
squares = map(square, inputs)
Expressions instead of statements is a key tool to make things declarative; the functional and logic paradigms are both declarative programming paradigms, as opposed to the structured/procedural and OO paradigms, which are imperative.
That they're also present in the functional and logic paradigms doesn't change that. It's a feature common to both, so not a feature that can be used to distinguish the categories from each other.
And regarding expressions, Rust is more expression oriented than most mainstream procedural languages today, and it's not declarative, though it may have more declarative-style (particularly its heavy use of the iterator style) compared to many other imperative languages.
“Declarative” and “imperative” are not really features of languages in the first place. They are features of code (and coding paradigms), and you can write code of either style (and usually most paradigms) in almost any real-world, Turing-complete, higher-level-than-assembly language.
The specific replacement of an imperative loop with a map call you made the non-sequitur response about function calls to upthread however, made the code it was in more declarative, though, and is typical of the ways that the functional paradigm (where map is typically the idiomatic way to do that) is more declarative than the structured/procedural paradigm (where building up a collection in an imperative loop would be.)
There’s a sort of useless sense in which everything is declarative if you are allowed to shift around what the relevant “thing to be done” is, and it seems like many people are complaining that the article does this exact thing.
Declarative: N(N+1)/2
Imperative: for(int sum=0, int i=1; i<=N; i++) {sum = sum+i;}