Whether the system charged with realizing desired states reasons about the current state is actually not relevant. Declarative systems work by generating the desired state 'from scratch', often with some kind of efficient cache.
A declaratively styled configuration system which still works by transitioning the system between target states statefully is still subject to the same problems as imperative configurations, but they're abstracted away from your field of view, as long as things sort of work.
A stateless approach, also typically (always?) configured in a declarative style, actually addresses these problems in a principled way. For an example, consider NixOS vs. Puppet, Chef, Ansible, etc.: https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansibl...
I like that essay's term for the paradigmatic differences, rather than the merely stylistic differences between imperative and declarative configurations: convergent vs. isomorphic.
What do you mean with "stateless" here, and which of those meet the stateless criteria? I have a hard time imagining any of those without state.
Deployments of server applications do usually involve some inherent state, like the contents of a database or the fact of which services are running. In that respect, some deployment tools in the Nix ecosystem are not isomorphic. But the software management and package management components, for example, are declarative without involving any reasoning about the current state. It is in that sense that those components are 'stateless' in a way that the rule of thumb proposed in the GP is not.
This is an option, but it is certainly not a requirement. If I say "I want cheeseburger", it is irrelevant to me if the cheeseburger is made from scratch or had been partially assembled ahead of time.
You are concerning yourself solely with configuration that can be generated not only declaratively, but also fully deterministically, but configuration systems can indeed exist where the environment isn't sufficiently deterministic. In such cases, taking the current state of the world, the user's request, and then determining the appropriate (and preferably minimal) actions to take to harmonize those without having to have them specified by the user is a declarative approach.
For example, I can go to the AWS console and turn up a job with a set of parameters, or I can have a configuration file and a daemon and if
{
cpu: 5,
mem: 20,
image: "my_docker_url",
}
import cc, ld, glob, make
// make defined as:
fn make(to, from, how) {
if (exists(to) && mtime(from) <= mtime(to) {
return
}
how(to, from)
}
make("foo.o", "foo.c", cc)
…
make("a.out", glob("*.o"), ld)
The Makefile is a (default) goal and a sea of possible actions from which make creates a plan of action.
The shell script steps are manually ordered by the programmer.
To give an example familiar to this forum: imagine we’re building a package. This can be set up imperatively with a shell script, or declaratively with GNU Make. Make will figure out which output files are missing or older than their input files, constituting a difference. It will figure out (topological sorting) an admissible path through computing a new up to date file from input files that are already up to date (re their own input files). Now that’s cool and all. But the same end result can be achieved way simpler if you can skip the diffing bit. If you assume you’re doing a clean build, you can order your build steps optimally in a shell script, skipping the now useless complexity. If there has been an abandoned rub that had some successful steps, your shell script will waste their results, but still end in a correct state.