Imperative configs are out; Declarative configs are in

<i>&quot;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.&quot;</i><p>There is no such thing as an imperative or declarative &quot;flow&quot;. By its very definition, declarative does not have &quot;flow&quot;. It is just a statement. Imperative (in programming) literally means &quot;describing steps that change state&quot;. Declarative (in programming) literally means &quot;describing a state which is desired&quot;.<p>Declarative would be &quot;I want a cheeseburger.&quot; Imperative would be &quot;Get me a bun, and some lettuce, and tomato, and mayo, and raw meat. Cook the meat on a grill at high heat, flipping half way. Put the mayo on the bottom of the bun, then the meat, then the lettuce, then the tomato, then put on the top of the bun. Give it to me.&quot;<p>It&#x27;s still strange to me how people learn about &quot;magic words&quot; like declarative and imperative, and then try to ssstttrrreeeeettttttcccccccchhhhhhhhhhh their meaning into some new paradigm that they have just thought up.<p>There is no such thing as an imperative configuration file. A configuration file describes how a program should be configured. Even when the configuration file &quot;describes a series of steps to change state&quot;, it&#x27;s <i>still declarative</i>, because the <i>configuration file</i> is still declaring <i>to the program</i> how to operate. It&#x27;s <i>the program</i> that is imperative or declarative, depending on how it <i>interprets and acts on</i> the configuration file. (This is made clearer in programs like Ansible, which, within the exact same configuration file, supports both declarative and imperative statements)<p>Before you say &quot;what about template files! jinja2! go templates! hcl!&quot;, that is merely a DSL, which is no longer a configuration file; it is effectively a program in a crude programming language, interpreted by an interpreter (the program loading the file).<p><i>(edit: I agree with the author&#x27;s point! But I suggest we stop using these terms &#x27;declarative&#x27; and &#x27;imperative&#x27;, and instead say &quot;let&#x27;s write programs that are functional enough that we don&#x27;t need to write configuration files that are mini-programs&quot;)</i>

I.... don&#x27;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.<p>That said, declarative clearly has advantages when it can work. You probably still want a &quot;break glass&quot; way to see what the actual steps that will be taken are, but can get surprisingly far without that.

This is an old debate surely? My first awareness of it was probably related to Django&#x27;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.<p>The counter-argument is that declarative configs inevevitably sprout programming-like features - and if they don&#x27;t someone will write code to generate them.<p>(disclaimer - in true HN fashion I haven&#x27;t properly RTFA&#x27;d - dinner is nearly ready and I&#x27;m feeling bold)

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

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.<p>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.<p>Thus the entire premise of the article thus seems to boil down to: If someone has already done the work, don&#x27;t re-do it.<p>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.

My two cents on the declarative vs imperative debate:<p>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&#x2F;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.<p>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.<p>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.

Declarative is great if there is always one path to get to where you&#x27;re going.<p>But I like to use the example of a Git repository where you&#x27;ve renamed and also changed some parts of a file. You commit the new state - was it a deletion and a brand new file, or a migration and modification of an existing resource? It&#x27;s usually a non-issue because Git is smart, and files don&#x27;t really care about their identity - but what if this was a database server and you need control over what happens when, and how things drain? Do you trust the system to choose the right path vs. &quot;delete the database and make a new one?&quot;<p>At some point you&#x27;ll need imperative thinking to make sure your bases are covered, even if that is &quot;we have a 3 phase rollout plan for different versions of the declarative config.&quot; And that&#x27;s perfectly fine, in many cases. But it&#x27;s important to never get into a cargo-cult level of &quot;if it can&#x27;t be done with one declarative change it shouldn&#x27;t be done&quot; - because then you&#x27;ll either get stuck or light things on fire.

This example is backwards:<p>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.<p>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 <i>backwards</i>.

&gt; <i>If a pipeline fails halfway, most CD systems don’t have the ability to retry. The only option is to restart a pipeline from the very beginning. Now with declarative configs, an intelligent delivery system, the system will detect that staging is already on the desired version and skip that push, allowing you to deliver value to your customers faster.</i><p>Hey, an interrupted &quot;make&quot; can always restarted from where it left off without ever having to do a &quot;make clean&quot;, so what could go wrong.

Complicated static configs are out; Scripts as configs (like Neovim) are in.<p>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.

As a recent NixOS convert, I concur

Declarative: Specify the result you want. Imperative: Specify (step by step) how to get the result you want.<p>Examples:<p>Declarative: I want a PC with the following code installed: X, Y and Z. Imperative: First upgrade X, then install Y, then uninstall W, then install Y and Z.

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

A good overview of why legacy CD systems cause so much pain in cloud-native environments

&gt; The config has now more than doubled in line count, making it impossible to remember the original intent of the configuration.<p>Not really, I found it quite self-explanatory.

Hey author: your css seems off on mobile. Text reads fine, but code looks tiny in comparison

This just looks like a frontend over kubernetes.

Ahh yes, the old stuff is new again. Ansible.

&gt;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.<p>LOL, he got it backwards, &quot;turn-by-turn directions&quot; is the imperative flow. Can&#x27;t expect much after reading that.