[0xbadcafebee]

> 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 some concrete and inviolable paradigm of computing. Some academics just wanted to tell people to write programs where you didn't have to spell out every instruction to the compiler, so they made this crude distinction. Things like a function called give_me_a_temporary_file(), rather than writing out an entire function yourself to create and return a temporary file. But both are executing steps imperatively under the hood. So we shouldn't make a big deal about these terms or programs that do more of one or the other.

The differences that I'm pointing out are 1) declarative does not describe a flow, the flow is under the hood; and 2) configuration files do not actually perform steps, they merely describe arbitrary data, and only the program interpreting the configuration can determine if the result is imperative or declarative. For some programs, the exact same configuration file may result in either imperative or declarative execution.

[jerf]

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

[phailhaus]

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

[0xbadcafebee]

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.

[phailhaus]

Where's the execution detail? He never tells you how the config file is going to be run. Again, the entire post is relative to the goal of getting a stable CI build. If your config file is filled with implementation details of that goal, you're being imperative.

It has nothing to do with "writing programs in your config file". The problem is that your config file is telling the runner how to reach the goal rather than what the goal is.

[lstodd]

> The problem is that your config file is telling the runner how to reach the goal rather than what the goal is.

The real-world alternative is a partial rewrite of your CI infra, which usually not feasible.

[tremon]

I don't think I agree with that. To me, the imperative vs declarative distinction is about the outside interface, not how the instructions are executed internally.

All code is also imperative, eventually, at the machine code level

But such a reduction is not useful. That's the same as stating that all computers are analog at the electrical level, or that the Internet is a series of tubes at the physical level.

Things like a function called give_me_a_temporary_file()

This seems purely imperative to me. A declarative statement would be (exists temporary_file). But that is a bad example anyway, as I struggle to find a good use case for why the end state of an instruction set would be the existence of a temporary file. If your goal is to perform subsequent steps with that temporary file, you're working with an imperative interface regardless of how you write it down.

[heavyset_go]

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