Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Imperative configs are out; Declarative configs are in

prodvana.io

Post reply on HN
Print view View original

61–70 of 94 posts

Re: Imperative configs are out; Declarative configs are in

#61

Post by ClumsyPilot »

0xbadcafebee wrote: post #9

"My dad switched from working with a map printout without knowing real-time conditions, the imperative flow, to Google Maps with turn-by-turn directions, the declarative flow." There is no such thing as an imperative or declarative "flow". By its very definition, declarative does not have "flow". It is just a statement. Imperative (in programming) literally means "describing steps that change state". Declarative (in…

> It's still strange to me how people learn about "magic words" like declarative and imperative, and then try to ssstttrrreeeeettttttcccccccchhhhhhhhhhh their meaning into some new paradigm that they have just thought up.

Develipera make fun of how project managers call anything Agile without understanding what it means, then go and commit the same sin themselves.

Re: Imperative configs are out; Declarative configs are in

#62

Post by taeric »

scubbo wrote: post #59
taeric wrote: post #55

Earlier quoted context omitted.

Because "burn it all down and rebuild everything" is by far the easiest orchestration to create from a declarative config. And is almost certainly not what any technician is going to want to happen to their production system.

Sort-of a nitpick, but for stateless services that's _precisely_ what you want to happen!

Not when your infrastructure includes your data store, though. Or if it includes such things as your application endpoint. You may want to stand up the new endpoints and then drain over traffic, as an example. Not take an outage for a deployment.

Re: Imperative configs are out; Declarative configs are in

#63

Post by btown »

Declarative is great if there is always one path to get to where you're going.

But I like to use the example of a Git repository where you've renamed and also changed some parts of a file. You commit the new state - was it a deletion and a brand new file, or a migration and modification of an existing resource? It's usually a non-issue because Git is smart, and files don't really care about their identity - but what if this was a database server and you need control over what happens when, and how things drain? Do you trust the system to choose the right path vs. "delete the database and make a new one?"

At some point you'll need imperative thinking to make sure your bases are covered, even if that is "we have a 3 phase rollout plan for different versions of the declarative config." And that's perfectly fine, in many cases. But it's important to never get into a cargo-cult level of "if it can't be done with one declarative change it shouldn't be done" - because then you'll either get stuck or light things on fire.

Re: Imperative configs are out; Declarative configs are in

#64

Post by lrem »

phailhaus wrote: post #15
0xbadcafebee wrote: post #9

"My dad switched from working with a map printout without knowing real-time conditions, the imperative flow, to Google Maps with turn-by-turn directions, the declarative flow." There is no such thing as an imperative or declarative "flow". By its very definition, declarative does not have "flow". It is just a statement. Imperative (in programming) literally means "describing steps that change state". Declarative (in…

> Even when the configuration file "describes a series of steps to change state", it's still declarative, because the configuration file is still declaring to the program how to operate Not sure I buy that logic. With that reasoning, all code is declarative because it's "declaring to the interpreter/compiler" how to operate. I think he's making the same point you did. In one case, the config file is laying out a sequ…

This is an important concept in my work. From experience, there is a pretty simple litmus test. It is pretty well understood that the word “imperative" denotes a system where the user describes a series of steps. The system executes the steps, in the end result bringing its universe to a desired state. The user does not need to describe what that is to the system, but a proof of correctness would decide whether that has been reached. Now, a declarative system is one where the user describes the desired end state and invariants on the admissible intermediate states of the universe. The system needs to figure out the current state of the universe, find the difference and find an admissible path to eliminate the difference. The litmus test to discern the two types of systems is whether the system concerns itself with the difference as a primary concept.

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.

Re: Imperative configs are out; Declarative configs are in

#65

Post by throwawaaarrgh »

atomicnumber3 wrote: post #45
phailhaus wrote: post #15

Earlier quoted context omitted.

> Even when the configuration file "describes a series of steps to change state", it's still declarative, because the configuration file is still declaring to the program how to operate Not sure I buy that logic. With that reasoning, all code is declarative because it's "declaring to the interpreter/compiler" how to operate. I think he's making the same point you did. In one case, the config file is laying out a sequ…

I find discussions like this ("html is/isn't a programming language" etc) kind of tiresome because eventually you end up at "a compiler is a file format converter". You have reached Truth but it ends up not being a terrifically interesting statement and everyone just kind of goes back to whatever they originally meant with whatever they said that started the argument.

Most people don't know that YAML is not a configuration format, because they never learned the difference between a configuration format and a data format. Once you know the difference, it's clear they are very different things, and when to use which, which leads to very different outcomes.

The more accurate people's words are, the clearer they can communicate their ideas. Better communication leads to better results.

Re: Imperative configs are out; Declarative configs are in

#66

Post by marcosdumay »

phailhaus wrote: post #15
0xbadcafebee wrote: post #9

"My dad switched from working with a map printout without knowing real-time conditions, the imperative flow, to Google Maps with turn-by-turn directions, the declarative flow." There is no such thing as an imperative or declarative "flow". By its very definition, declarative does not have "flow". It is just a statement. Imperative (in programming) literally means "describing steps that change state". Declarative (in…

> Even when the configuration file "describes a series of steps to change state", it's still declarative, because the configuration file is still declaring to the program how to operate Not sure I buy that logic. With that reasoning, all code is declarative because it's "declaring to the interpreter/compiler" how to operate. I think he's making the same point you did. In one case, the config file is laying out a sequ…

> With that reasoning, all code is declarative because it's "declaring to the interpreter/compiler" how to operate.

Well, yes. Those words are not as well defined as common usage implies. Their meaning is completely dependent on what you define as your basic operations.

People usually agree on some large spaces of incomplete definitions, so the terms aren't meaningless without context. But never everybody agree, and never most people agree on all the details.

Anyway, configuration files is one context where people have very diverse concepts of basic operations, and so most people almost never agree.

Re: Imperative configs are out; Declarative configs are in

#67

Post by pxc »

lrem wrote: post #64
phailhaus wrote: post #15

Earlier quoted context omitted.

> Even when the configuration file "describes a series of steps to change state", it's still declarative, because the configuration file is still declaring to the program how to operate Not sure I buy that logic. With that reasoning, all code is declarative because it's "declaring to the interpreter/compiler" how to operate. I think he's making the same point you did. In one case, the config file is laying out a sequ…

This is an important concept in my work. From experience, there is a pretty simple litmus test. It is pretty well understood that the word “imperative" denotes a system where the user describes a series of steps. The system executes the steps, in the end result bringing its universe to a desired state. The user does not need to describe what that is to the system, but a proof of correctness would decide whether that…

> Now, a declarative system is one where the user describes the desired end state and invariants on the admissible intermediate states of the universe. The system needs to figure out the current state of the universe, find the difference and find an admissible path to eliminate the difference. The litmus test to discern the two types of systems is whether the system concerns itself with the difference as a primary concept.

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.

Re: Imperative configs are out; Declarative configs are in

#69

Post by 8jy89hui »

Complicated static configs are out; Scripts as configs (like Neovim) are in.

Both of these examples seem like they would be better fit with Lua-based configs. Scripts as configs give incredible amounts of power to the user without the programmer having to specify everything the user might want to do.

Re: Imperative configs are out; Declarative configs are in

#70

Post by thenipper »

rgovostes wrote: post #58

As a university student discovering constraint solvers like Z3, I believed that the future of computing was declarative programming, with black box solvers that would obviate the need for specialized algorithms. Dealing with Webpack cured me of the idea that declarative is strictly superior. Configuring it is just endlessly consulting the documentation, and then the underlying code, and then cargo culting StackOverfl…

There is a ton of interesting work being done with solvers adjacent to machine learning. I just finished a job where I was working with an operations research team solving inventory placement and transportation
Post reply on HN