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

71–80 of 94 posts

Re: Imperative configs are out; Declarative configs are in

#71

Post by tremon »

pxc wrote: post #67
lrem wrote: post #64

Earlier quoted context omitted.

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 co…

A stateless approach [..] For example, consider NixOS vs. Puppet, Chef, Ansible

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.

Re: Imperative configs are out; Declarative configs are in

#72

Post by tremon »

0xbadcafebee wrote: post #20
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…

> With that reasoning, all code is declarative because it's "declaring to the interpreter/compiler" how to operate. Sort of! All code is also imperative , eventually, at the machine code level. This is a perfect example of how useless the whole "imperative vs declarative" distinction is. Nearly everything in a computer is both imperative and declarative, in some fashion, at some point. These terms were not made to be…

I don't think I agree with that. To me, the imperative vs declarative distinction is about the outside interface, not how the instructions are executed internally.

All code is also imperative, eventually, at the machine code level

But such a reduction is not useful. That's the same as stating that all computers are analog at the electrical level, or that the Internet is a series of tubes at the physical level.

Things like a function called give_me_a_temporary_file()

This seems purely imperative to me. A declarative statement would be (exists temporary_file). But that is a bad example anyway, as I struggle to find a good use case for why the end state of an instruction set would be the existence of a temporary file. If your goal is to perform subsequent steps with that temporary file, you're working with an imperative interface regardless of how you write it down.

Re: Imperative configs are out; Declarative configs are in

#73

Post by lstodd »

phailhaus wrote: post #49
0xbadcafebee wrote: post #40

Earlier quoted context omitted.

Well, he does get into execution detais; he's showing you multiple configs that have a lot of steps in series, and saying, "Look, this file is ridiculous! Too many steps! Bugs! Instead, just define one function! Let the program deal with it!" Which I 1000% agree with. I get that the whole story is saying "do things declaratively". But I think that term, and its ability to be misused (as in the quoted example) are dis…

Where's the execution detail? He never tells you how the config file is going to be run. Again, the entire post is relative to the goal of getting a stable CI build. If your config file is filled with implementation details of that goal, you're being imperative. It has nothing to do with "writing programs in your config file". The problem is that your config file is telling the runner how to reach the goal rather tha…

> The problem is that your config file is telling the runner how to reach the goal rather than what the goal is.

The real-world alternative is a partial rewrite of your CI infra, which usually not feasible.

Re: Imperative configs are out; Declarative configs are in

#74

Post by tremon »

taeric wrote: post #62
scubbo wrote: post #59

Earlier quoted context omitted.

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.

Not when your infrastructure includes your data store, though

Then the service is no longer stateless.

Re: Imperative configs are out; Declarative configs are in

#75

Post by tremon »

bastardoperator wrote: post #53

You might end up with the nightmare config they highlighted if the person writing the config has no semblance of DRY, but it's unlikely someone versed in CD systems isn't going to use techniques afforded to them for reducing boilerplate.

The irony is that many declarative systems have very poor support for symbols, templates, and code reusability in general, so declarative configurations carry more boilerplate than imperative configurations.

Re: Imperative configs are out; Declarative configs are in

#76

Post by pxc »

tremon wrote: post #71
pxc wrote: post #67

Earlier quoted context omitted.

> 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 co…

A stateless approach [..] For example, consider NixOS vs. Puppet, Chef, Ansible 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.

NixOS has atomic transitions between independent configuration states. So for a simple example, when you uninstall a program from your declared NixOS config and request a switch of configurations, NixOS does not take into consideration your current configuration so that it can uninstall those removed packages. Instead, it generates a brand new filesystem tree from scratch which does not include those packages. Similarly, configuration files are never edited in place, even with a guarantee of idempotency; they're regenerated from scratch.

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.

Re: Imperative configs are out; Declarative configs are in

#77

Post by lamontcg »

8jy89hui wrote: post #69

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.

If they pull in dependencies that can make them very non-portable, while that is typically where all their power comes from over normal config files.

Re: Imperative configs are out; Declarative configs are in

#78

Post by taeric »

tremon wrote: post #74
taeric wrote: post #62

Earlier quoted context omitted.

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.

Not when your infrastructure includes your data store, though Then the service is no longer stateless.

I mean, you aren't wrong. But I am challenged to think of a service that doesn't store state somewhere.

And you ignore the other situation. Even a fully "stateless" service that literally just responds to things probably doesn't want an outage just to deploy a new version.

Re: Imperative configs are out; Declarative configs are in

#79

Post by rcarr »

My two cents on the declarative vs imperative debate:

Yes all code is eventually imperative if you go down low enough. But your code should be as declarative as possible for your user. For example, the business department write a ticket for me to build a new feature. They essentially declare some functionality. I then take the imperative steps to code that on the front or back end. To do this, I will likely need to use some tooling. As far as the tooling is concerned, I am now the user/business department, I declare what I want in the tooling and the tooling should make it for me. The developers of the tooling then write imperative code to handle that. Maybe they rely on tooling to do so, in which case they become the user and so on. The cycle repeats itself recursively until it reaches the machine code at the bottom.

You could even take it further if you like in that the hardware engineers behind the processors are now the developers carrying out the imperative functionality who in turn carry out their job using electronic measuring tools which makes them users etc.

Basically, everything should be declarative by default for the intended user of the application unless they have specifically requested finer grained control. The user has enough to deal with getting their particular task done, they shouldn’t have to navigate between layers building the tools that they need to get their job done. Unless he’s working on something unique that requires it, the tradesman doesn’t want to go to the DIY store and give them instructions to build a drill, he just wants to buy a drill that meets his requirements so he can get on with his job.

Re: Imperative configs are out; Declarative configs are in

#80

Post by eternityforest »

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…

The common meaning of imperative means you tell a computer something step by step. If a config file does that, it's imperative.

Declarative in practice usually means that an intelligent solver works backwards from a description of a final state

Make a file is imperative. There should be a file here is delarative.

Making a file may fail depending on implementation if it already exists. "This file should exist" likely will not because it will do whatever is needed, including nothing, to ensure constraints are met.

The best configuration file in my opinion, though, is to keep it trivial, and just have one factory config with very few options.

Need to log in and think you need to set a username and password? Linux has that already, lots of apps use the user accounts instead of their own nonsense layer or even directly use SSH as their transport.

Need to enable optional modules? Can you just make them enable and disable themselves on demand?

Network settings? I hope there's at least the option to just discover everything automatically.

Post reply on HN