[deleted]
Imperative configs are out; Declarative configs are in
31–40 of 94 posts
Re: Imperative configs are out; Declarative configs are in
#32This 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…
> The counter-argument is that declarative configs inevevitably sprout programming-like features - and if they don't someone will write code to generate them.
Ha! See the make manual for examples.
Background reading: https://stackoverflow.com/questions/3480950/are-makefiles-tu...
Re: Imperative configs are out; Declarative configs are in
#33"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…
Very good breakdown. Couldn't agree more.
Except that mayo should go on top.
Re: Imperative configs are out; Declarative configs are in
#34Earlier 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…
> configuration files do not actually perform steps
And I don't think he's saying they do either. In fact, I don't think the post gets into execution details at all! If you go through it again, he's only talking about ways of writing config files, not ways of running them. In one approach, the config defines the pipeline itself. In the second approach, the config defines your desired end state.
The "imperative" vs "declarative" distinction is entirely dependent on what your goal is. If your goal is to write a very specific pipeline, then the former is also declarative! But the context of the article is in achieving some desired end state in CI. With that context in mind, the former is "imperative" and the latter is "declarative".
Re: Imperative configs are out; Declarative configs are in
#35Earlier 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.
That makes sense. I'm not necessarily arguing for continuous intelligence in this post, just that declarative configs enable it. Even the initial conversion of a destination to a set of directions is a compilation of declarative to imperative. Imagine if Google Maps was truly imperative and asks you to input the individual roads you want ahead of time - then it would not be useful.
> Imagine if Google Maps was truly imperative and asks you to input the individual roads you want ahead of time - then it would not be useful.
I'd love to be able to have the ability to request specific roads in Google Maps directions, as it is you have to jury-rig imperative elements by adding waypoints at the start and end of the route you want included.
This illustrates me point: Systems for transforming declarations into imperative steps will always have limitations in terms of what can be declared and what states that can generate good imperative steps from/to. Once you step outside those limitations, you inevitably need to re-introduce some amount of your own imperative configuration. Ideally, eventually you make that imperative logic declaratively configurable and contribute that back to the commmunity.
Re: Imperative configs are out; Declarative configs are in
#36Earlier quoted context omitted.
I guess I should have said "voice-guided" turn-by-turn huh? https://www.forbes.com/sites/anthonykosner/2012/12/13/google... is what i was referring to :)
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.
Re: Imperative configs are out; Declarative configs are in
#37"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…
Very good breakdown. Couldn't agree more. Except that mayo should go on top.
I don't disagree, but a lot of burgers end up dry, so the bottom bun stays dry and bland, which makes me sad. Sauce on the bottom solves that, and the top bun gets wet from the tomato. Optimizing for the 80% burger.
Re: Imperative configs are out; Declarative configs are in
#38Earlier 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…
"All code is also imperative, eventually, at the machine code level."
This is essentially what I think, and I've thought for a long time: https://news.ycombinator.com/item?id=3507281
To the extent that people say "But what about..." my answer is that there isn't a particularly useful line to draw between imperative and declarative. There is one; I can draw it too. I challenge its usefulness. Imperative things have too many declarative things mixed in, and vice versa, in practice for it to be a very useful metric. I find what I mentioned in that post about the ease of debugging to be the real information I get when someone uses the "declarative" phrase; I can pretty much count on things breaking and me being unable to fix things whenever I see that word used.
I find it much more useful to mix things up as appropriate and not sweat which things they happen to be. A "declarative style" is a useful tool to be used, little more, and it almost never belongs in any sort of pro or con list. The pros or the cons should be at the next level down, like, "it's hard to debug" or "I'm typing way too much for what I'm trying to accomplish". I haven't evaluated any techs and given or subtracted points merely for being or not being "declarative" in a long time.
Re: Imperative configs are out; Declarative configs are in
#39Declarative works better than imperative only when someone has already defined the imperative process that takes you from any given state to your goal and does that for you based on your declaration. Google maps works great for a set of origins to a set of departures for certain modes of travel. Once you get outside those bounds, it can fail in significant ways. Thus the entire premise of the article thus seems to bo…
This is the correct answer.
You can declare only when someone else already has performed the imperative chore, i.e. written the source code, programmed.
Q.E.D.
Re: Imperative configs are out; Declarative configs are in
#40Earlier quoted context omitted.
> 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…
> configuration files do not actually perform steps And I don't think he's saying they do either. In fact, I don't think the post gets into execution details at all! If you go through it again, he's only talking about ways of writing config files, not ways of running them. In one approach, the config defines the pipeline itself. In the second approach, the config defines your desired end state . The "imperative" vs "…
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 distracting, because we get lost in the weeds and miss the real point, which is that we shouldn't be writing pseudo-programs in configuration files. I think we can all agree on that; so let's just say that, and leave the magic words alone.