[taeric]

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.

[everforward]

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.

[taeric]

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.

[naphatkrit]

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.

[taeric]

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.)

[shkkmo]

> 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.