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

21–30 of 94 posts

Re: Imperative configs are out; Declarative configs are in

#21

Post by TOGoS »

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…

Right. I think the important distinction is whether an imperative language is used to describe things that could be done purely declaratively, as is the case with Gradle[1]. I think this happens all too often because the oldschool declarative system has some edge case that it can't handle, so someone reinvents it with a fake DSL which is actually a dialect of an imperative language, and now you have the worst of both worlds. I've always thought that what we needed was a way to allow both declarative and functional information to be provided, but with a clearer separation between the two. e.g. a build configuration language based on this approach might allow one to specify either 'buildArtifactId: "xyz123"' or 'buildArtifactIdExpression: (functional expression to compute a build artifact ID goes here)'.

I sort of tried to do this with the Factorio terrain generation system[2]. The first phase is to run a Lua program, which is imperative, but the result is an immutable object representing the terrain generation configuration, which in turn includes functional expressions, since a map where everything is constant would be boring.

[1] I f&!@#^ing hate Gradle; it is my go-to example of thoughtlessly mashing paradigms together because you can, resulting in something that nobody I have ever met really has really been able to work with except by trial and error.

[2] See https://factorio.com/blog/post/fff-200 and https://togos.github.io/togos-example-noise-programs/

Re: Imperative configs are out; Declarative configs are in

#22

Post by zmgsabst »

This example is backwards:

Showing a map printout while ignoring runtime state is declarative; executing directions step by step, adapted to the present state of the system, is imperative.

I’ll set aside my feelings about stretching meaning to say — if you are going to use technical words this way, don’t use them backwards.

Re: Imperative configs are out; Declarative configs are in

#23

Post by moralestapia »

naphatkrit wrote: post #16
phailhaus wrote: post #13

Earlier quoted context omitted.

I was thinking the same thing, but his point is that with Google Maps you simply declare your end goal. It figures out how you should get there based on current conditions.

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:

Re: Imperative configs are out; Declarative configs are in

#24

Post by taeric »

naphatkrit wrote: post #10
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.

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.

Apologies if it sounded like I didn't like the post. I think the rest of it was great and your point, I think, is conveyed well. I just got hung up on the lead in.

Getting any directions from a system will be hard to turn into an imperative process, to be honest. It is imperatively telling you what to do, already. And, amusingly, you typically use an imperative to activate it. "Google, show me directions from here to ____." Literally an imperative voice cue. (I think you can twist this to be more "I want directions from here to there," such that it is not imperative, but this feels like it is stretching.)

Declarative would be a bit more itinerary based. You fill in a few details of "On this day/time, I want bagels. On this day/time, I want to be at a hotel in the city. Etc." Then, it would output a list of steps on how you could make that work.

And this ties it in nicely with infrastructure config. Especially at the beginning when you don't have pre-existing state of services, you can quite easily declare what you want. It is more when you have to also start defining migrations that you are likely to drop into imperative steps. (Really, any management of state transition will almost certainly be easier using imperative.)

Re: Imperative configs are out; Declarative configs are in

#25

Post by taeric »

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…

> There is no such thing as an imperative configuration file

My Emacs config would like a word with you. :D

Re: Imperative configs are out; Declarative configs are in

#26

Post by thfuran »

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…

>There is no such thing as an imperative configuration file.

Clearly you haven't seen the gradle files I have been subjected to.

Re: Imperative configs are out; Declarative configs are in

#27

Post by [deleted] »

taeric wrote: post #4

I.... don't buy the initial example. Google maps is still an imperative list of directions. It just keeps track of the current pointer for you, and is able to reroute. If anything, that is an example that a dynamic action plan is more adaptable than a static one. That said, declarative clearly has advantages when it can work. You probably still want a "break glass" way to see what the actual steps that will be taken…

[deleted]

Re: Imperative configs are out; Declarative configs are in

#28

Post by rising-sky »

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…

I had the same thought when I read that paragraph and anecdotal tortured "lost with map printout" description, immediately thought, not sure this author knows quite what they are talking about, but kept reading to see what the configuration would look like...

> ssstttrrreeeeettttttcccccccchhhhhhhhhhh

apt

Re: Imperative configs are out; Declarative configs are in

#29

Post by shkkmo »

Declarative 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 boil down to: If someone has already done the work, don't re-do it.

The problem with declarative configuration is that as the systems they manage become more complex, inevitably you leave the bounds of the solved problem and have to start solving it for yourself imperatively.

Re: Imperative configs are out; Declarative configs are in

#30

Post by gtirloni »

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…

The whole article is an ad.
Post reply on HN