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

51–60 of 94 posts

Re: Imperative configs are out; Declarative configs are in

#51

Post by heavyset_go »

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…

Python's setuptools configuration file via setup.py can perform steps, it's literally just a Python script.

Re: Imperative configs are out; Declarative configs are in

#52

Post by everforward »

taeric wrote: post #8
naphatkrit wrote: post #6

Earlier quoted context omitted.

Oh totally that declarative can and will often compile down to imperative. The question is what do you ask the user for? My take is Google maps is declarative in the sense that you ask for your destination, your constraints (e.g. no highway), and time to leave, and it dynamically generates the underlying imperative steps like you said (but continuously adapt if you go off course, which you cannot do unless the initia…

That example still feels off. The "offline printout" was done in a very declarative way. It is just fixed on the execution plan. (And, quite frankly, less obnoxious to me if I decide to stop and get gas or food.) You can even prepare alternative routes ahead of time, if you want to speculate on conditions. Is a good idea to role play some of that ahead of the time, in any case.

Declarative stuff gets converted to imperative at execution time. A significant difference is that a declarative system is not dependent on a particular state.

Telling a site to get you from X to Y is declarative, because X can be anything and it works. The printed out instructions are imperative, and only work for a fixed X or somewhere already on the path.

Maps is more declarative because it continually generates imperative instructions to get to Y regardless of where you currently are.

Re: Imperative configs are out; Declarative configs are in

#54

Post by taeric »

everforward wrote: post #52
taeric wrote: post #8

Earlier quoted context omitted.

That example still feels off. The "offline printout" was done in a very declarative way. It is just fixed on the execution plan. (And, quite frankly, less obnoxious to me if I decide to stop and get gas or food.) You can even prepare alternative routes ahead of time, if you want to speculate on conditions. Is a good idea to role play some of that ahead of the time, in any case.

Declarative stuff gets converted to imperative at execution time. A significant difference is that a declarative system is not dependent on a particular state. Telling a site to get you from X to Y is declarative, because X can be anything and it works. The printed out instructions are imperative, and only work for a fixed X or somewhere already on the path. Maps is more declarative because it continually generates i…

Right, but the point is that when you are in the execution, you are back in the imperative. And with google maps, you are almost always in the execution side. Is why I said that would be a better example for dynamic plans being better than static ones.

I'd go further and say that not just dynamic and static, but interactive versus non-interactive is the showcase there. Declarative/imperative is just not that applicable to that scenario.

And again, I do like the rest of the article and the idea that is getting explored. I just question if that is really a great example for declarative/imperative. You have to squint to make it work, for whichever version you want to support.

Re: Imperative configs are out; Declarative configs are in

#55

Post by taeric »

naphatkrit wrote: post #5
andybak wrote: post #3

This is an old debate surely? My first awareness of it was probably related to Django's settings.py back around 2007 but I got the feeling from discussions then that it was a discussion that had been bouncing around for a long time before that. The counter-argument is that declarative configs inevevitably sprout programming-like features - and if they don't someone will write code to generate them. (disclaimer - in t…

Yep the idea of declarative winning out over imperative is nothing new. Yet for some reason, most deployment systems make you go through an imperative flow if you want to orchestrate releases.

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.

Re: Imperative configs are out; Declarative configs are in

#57

Post by WastingMyTime89 »

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…

You are missing the forest for the trees by confusing the end result with its implementation.

The idea between having a declarative configuration vs a traditional one is well understood in the context of a machine. In one case, you describe how you want the final machine to look like and let the system decides how to reach that states, in the other you yourself input how the state will be changed step by step to reach the final stage. Sure the declarative configuration really is a DSL and there is an interpreter somewhere turning it into a step by step list of actions but that’s invisible to the end user.

It’s not magic just abstracted. That’s the good old Wheeler aphorism: “ There is no problem in computer science that can't be solved using another level of indirection.”

Re: Imperative configs are out; Declarative configs are in

#58

Post by rgovostes »

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 StackOverflow answers to coerce the black box to create the output I want.

Re: Imperative configs are out; Declarative configs are in

#59

Post by scubbo »

taeric wrote: post #55
naphatkrit wrote: post #5

Earlier quoted context omitted.

Yep the idea of declarative winning out over imperative is nothing new. Yet for some reason, most deployment systems make you go through an imperative flow if you want to orchestrate releases.

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!

Re: Imperative configs are out; Declarative configs are in

#60

Post by saltcured »

phailhaus wrote: post #36
moralestapia wrote: post #23

Earlier quoted context omitted.

Huh? Voice or not, it's still imperative. :grimacing:

"Declarative" and "imperative" are relative to the goal you are trying to achieve. If your goal is only to reach your destination within some parameters, then writing down every single step to get there is imperative. The declarative approach is to specify the destination and those parameters, and allow the engine to determine how to get there.

Right, imperative directions would be the turn by turn recipe to get from A to B. Declarative directions would be "be at B". Route planning is the solution method to convert from declarative to imperative navigation directions.

Of course, it's also a nuanced value judgement. The declarative/imperative abstraction is almost fractal, as we could consider a trip with multiple intermediate destinations as either a declarative itinerary or an imperative plan. Or we could go further and talk about all the control steps it takes to "turn right in 100 meters".

What the article describes for the father's driving is the difference between ahead-of-time and just-in-time navigation. It's not a very good metaphor for declarative versus imperative configuration management. To turn it into one would make for a perverse story, i.e. telling the father where you want to meet versus telling the father a long list of turns starting from the airport while obfuscating the destination.

Post reply on HN