Why does nobody seem to know what imperative and declarative actually mean?(leebriggs.co.uk)
leebriggs.co.uk
Why does nobody seem to know what imperative and declarative actually mean?
https://leebriggs.co.uk/blog/2022/07/20/nobody-knows-what-declarative-is
10 comments
The clickbait title doesn't even summarise the problem, being that Pulumi lets you declare a desired state using an imperative language, and so people label it one way or the other and then proceed to get into internet arguments.
Yaml/dhall FTW btw, easiest way of preventing our resident greybeard from writing infra in a complex mess of python/js/bash is to not let them use python/js/bash.
Yaml/dhall FTW btw, easiest way of preventing our resident greybeard from writing infra in a complex mess of python/js/bash is to not let them use python/js/bash.
They have no inherent meaning. Terms like these are the result of laziness, and the embrace of smug obscurity.
There's a similar pair in video editing: you can "slip" or "slide" footage. I have no idea which is which, and I've written editing software. The terms are useless because they're non-descriptive, especially in discriminating between each other.
There's a similar pair in video editing: you can "slip" or "slide" footage. I have no idea which is which, and I've written editing software. The terms are useless because they're non-descriptive, especially in discriminating between each other.
Oh look its the Chef vs. Puppet imperative vs. declarative argument from 10 years ago...
Declarative resources all ultimately get built on top of imperative foundations, the fundamental building blocks of all these tools we use are imperative.
And the non-expert community of users likes to think in imperative terms and purely declarative abstractions are something that they have a lot of trouble with.
This is why people like Ansible's hacked-up YAML that they can write loops in.
After 20 years or so of configuration management I'm quite convinced that trying to push declarative programming styles directly onto the end user is quite a bit of a failure and produces hard-to-use tooling outside of expert circles (otherwise CFEngine would have been a huge commercial success and we wouldn't bother talking about anything else).
What succeeds is the ability to reuse declarative resources that someone else has written, composeably, to build up larger declarative resources, using imperative glue code. And there's nothing wrong with that because with all these tools the implementation of the declarative primitives is all imperative under the covers.
What we really need is some simple imperative configuration management language to give to users (ideally something about as complicated as the old ANSI C-book) which allow experts to easily plug into a DSL that exports declarative resources for the users, along with easy FFI support out to native libraries and probably ease of calling functions in external languages like python. Dhall is kinda sorta the right direction, but I think it is too based in FP to be broadly accessible to the people are using turing computable YAML.
If Pulumi is doing more or less what I just described then they're probably going down the right path more or less and its probably quite unfair to lob "imperative" at them like an insult, but that is what has been going on for at least the past 10 years though. I don't think there's a single tool out there that is fully imperative and doesn't expose declarative primitives and let you build on them.
Declarative resources all ultimately get built on top of imperative foundations, the fundamental building blocks of all these tools we use are imperative.
And the non-expert community of users likes to think in imperative terms and purely declarative abstractions are something that they have a lot of trouble with.
This is why people like Ansible's hacked-up YAML that they can write loops in.
After 20 years or so of configuration management I'm quite convinced that trying to push declarative programming styles directly onto the end user is quite a bit of a failure and produces hard-to-use tooling outside of expert circles (otherwise CFEngine would have been a huge commercial success and we wouldn't bother talking about anything else).
What succeeds is the ability to reuse declarative resources that someone else has written, composeably, to build up larger declarative resources, using imperative glue code. And there's nothing wrong with that because with all these tools the implementation of the declarative primitives is all imperative under the covers.
What we really need is some simple imperative configuration management language to give to users (ideally something about as complicated as the old ANSI C-book) which allow experts to easily plug into a DSL that exports declarative resources for the users, along with easy FFI support out to native libraries and probably ease of calling functions in external languages like python. Dhall is kinda sorta the right direction, but I think it is too based in FP to be broadly accessible to the people are using turing computable YAML.
If Pulumi is doing more or less what I just described then they're probably going down the right path more or less and its probably quite unfair to lob "imperative" at them like an insult, but that is what has been going on for at least the past 10 years though. I don't think there's a single tool out there that is fully imperative and doesn't expose declarative primitives and let you build on them.
Actually, everything is imperative at the end of the day because the processor executes instructions in a certain order.
"Declarative" is a style abstraction like other abstraction words (file, database, server, etc) that don't define anything by themselves. When code is actually run on a processor, that code is strictly imperative.
Any "declarative" code (like pure HTML) involves thousands of lines of tests and branches when it is actually run. It follows the input-process-output model like all programming.
I think we have lots of style wars in programming because many people don't know or don't think about how the physical components like processors and storage actually operate.
"Declarative" is a style abstraction like other abstraction words (file, database, server, etc) that don't define anything by themselves. When code is actually run on a processor, that code is strictly imperative.
Any "declarative" code (like pure HTML) involves thousands of lines of tests and branches when it is actually run. It follows the input-process-output model like all programming.
I think we have lots of style wars in programming because many people don't know or don't think about how the physical components like processors and storage actually operate.
Declarative and Imperative knowledge are best summed up in a cartoon
strip in Viz comic.
Both kinds are needed. There is a danger from an imbalance of these knowledge types.
A serious problem of our age is "unrequited declarative thinking" where there's an excess of abstraction. The degenerate software patent system, which allows vague "business model" claims, exemplifies this problem. We've become too used to technology working like magic and experiencing surface effects rather than understanding mechanisms that we forget someone, or something, somewhere has to actually do the work.
This is what Arthur C Clarke warned about, although typically, most people took his "indistinguishable from magic" statement as a positive endorsement of ignorance (ie. intuitive "just works" stuff that "doesn't make me think").
On the other hand we can have an excess of imperative thinking. Technocrats engage in over-systematisation and rigid mechanical ideation of the world because they forget Einstein's most important equation "Imagination is more important than knowledge".
Tom: "Hey Bob, I've just invented a new pill that cures cancer and turns
water into petrol"
Bob: Amazing work Tom. How does it work?
Tom: I've no idea. I only just invented it!
A rocket ship is a way to get to space. (Declarative)
We can escape the gravity of Earth in a self-contained vehicle
burning a fuel and oxygen mixture in a combustion chamber such that
it develops an exhaust thrust that exceeds the weight of the vehicle
and sufficient total energy to reach escape velocity. (Imperative)
[Of course we could make the latter *more* imperative by giving
finer details and equations.]
Both kinds are needed. There is a danger from an imbalance of these knowledge types.
A serious problem of our age is "unrequited declarative thinking" where there's an excess of abstraction. The degenerate software patent system, which allows vague "business model" claims, exemplifies this problem. We've become too used to technology working like magic and experiencing surface effects rather than understanding mechanisms that we forget someone, or something, somewhere has to actually do the work.
This is what Arthur C Clarke warned about, although typically, most people took his "indistinguishable from magic" statement as a positive endorsement of ignorance (ie. intuitive "just works" stuff that "doesn't make me think").
On the other hand we can have an excess of imperative thinking. Technocrats engage in over-systematisation and rigid mechanical ideation of the world because they forget Einstein's most important equation "Imagination is more important than knowledge".
I'm swayed.
I can imagine some would argue that having it in an imperative language means you can do if/else type things, but we hack the same thing into Terraform by abusing `count`. Everybody does it, certain situations make it unavoidable.
The only argument left against it in my mind, is that using an imperative language means it allows you to more easily employ anti-patterns to the declarative approach (either accidentally or deliberately). To that I'd have to say; ¯\_(ツ)_/¯ just don't do that?
I can imagine some would argue that having it in an imperative language means you can do if/else type things, but we hack the same thing into Terraform by abusing `count`. Everybody does it, certain situations make it unavoidable.
The only argument left against it in my mind, is that using an imperative language means it allows you to more easily employ anti-patterns to the declarative approach (either accidentally or deliberately). To that I'd have to say; ¯\_(ツ)_/¯ just don't do that?
Having a DAG and bring able to manipulate it doesn't make it declarative.
A DAG is a data structure and completely orthogonal to the language used to manipulate it
A DAG is a data structure and completely orthogonal to the language used to manipulate it
Imperative: must do now.
Declarative: assert what's to occur.
In SQL, DDL is declarative, DML is imperative.
And here's where I find out that I am "wrong".
Declarative: assert what's to occur.
In SQL, DDL is declarative, DML is imperative.
And here's where I find out that I am "wrong".
Because your handheld is not working? It was stolen perhaps? You forgot your login? You forgot that you can query Google? You live in a prison and aren't allowed access to a PC?
Please tell us: inquiring minds want to know!
Please tell us: inquiring minds want to know!
What are you on about?
Firstly b/c the OP's statement is not true. Secondly b/c the question is most easily answered with a simple Google query. It seems inappropriate for HN. I'll flag it FWIW.
The thing we should care about is the cognitive overhead of these languages and systems. Control flow adds to complexity, as does state. But often in declarative languages you’re still having to reason about what the underlying runtime is going to do with your declarations (SQL is a truly monstrous example of this).
I don’t think we’ve stumbled onto the final, best approach here. I suspect the long term answer isn’t the YAMLification of all things. It probably isn’t a JavaScript DSL either. In the longest of long terms I assume I can just hand my requirements to an AI at AWS and say “boot up something like that please”. Lots of room for interesting ideas in between!