4 ms·

I think it's just a weakness of the terms. Kind of like "interpreted vs compiled" at this point very little is strictly interpreted, almost everything goes thro

I think it's just a weakness of the terms. Kind of like "interpreted vs compiled" at this point very little is strictly interpreted, almost everything goes through a bytecode compilation step. In this case, you're using imperative languages to generate declarative policies. Things just aren't black and white. Importantly, it doesn't really matter. We say "Python is interpreted" because the it gives you the UX of an interpreted language. We say "Pulumi is imperative" because it gives you the UX of an imperative language. Under the hood they do their own thing, but unless you're trying to have a really precise conversation it's usually easiest to stick to those terms.

Dylan16807 4y ago
> We say "Pulumi is imperative" because it gives you the UX of an imperative language. Under the hood they do their own thing, but unless you're trying to have a really precise conversation it's usually easiest to stick to those terms. I'd still take issue with that description. There is a massive UX distinction here that isn't under the hood. Your imperative Pulumi code is at a meta/macro/preprocessor level. That's completely different from writing imperative code that manipulates your servers. Your code generates declarations. It does not take actions. Boiling that down to one word is likely not the best way of doing it, but I agree with the author that in this situation the function/output of what you write is more important than how it gets there. The stuff you write doesn't configure servers, it describes servers.
- staticassertion 4y ago
  I think ultimately you're just demonstrating the larger point. There is no value trying to label it as imperative or declarative except in the niche situation where one is debating whether it is imperative or declarative, which at some point is just a philosophical question. I think it was Plato who asked this question - if I take two pieces of clay and smash them together, which piece grew? You can argue all day about it, and it has some fun implications about identity, but that's philosophy.
  - Dylan16807 4y ago
    If you care about the type of thing you need to write, there's tons of reason to make the distinction. The thing about writing "code that outputs a data structure" is that you can voluntarily choose to use no control flow. The tool takes declarative input, and optionally you can use imperative code to make the job of writing that input easier. That's very different from a tool that gives you helper functions for writing an imperative core. In that case you're always writing something that's full of control flow, and it's up to you to make sure you get all the state transitions to be consistent with each other.

Dylan16807 4y ago

> We say "Pulumi is imperative" because it gives you the UX of an imperative language. Under the hood they do their own thing, but unless you're trying to have a really precise conversation it's usually easiest to stick to those terms. I'd still take issue with that description. There is a massive UX distinction here that isn't under the hood. Your imperative Pulumi code is at a meta/macro/preprocessor level. That's completely different from writing imperative code that manipulates your servers. Your code generates declarations. It does not take actions. Boiling that down to one word is likely not the best way of doing it, but I agree with the author that in this situation the function/output of what you write is more important than how it gets there. The stuff you write doesn't configure servers, it describes servers.

staticassertion 4y ago
I think ultimately you're just demonstrating the larger point. There is no value trying to label it as imperative or declarative except in the niche situation where one is debating whether it is imperative or declarative, which at some point is just a philosophical question. I think it was Plato who asked this question - if I take two pieces of clay and smash them together, which piece grew? You can argue all day about it, and it has some fun implications about identity, but that's philosophy.
- Dylan16807 4y ago
  If you care about the type of thing you need to write, there's tons of reason to make the distinction. The thing about writing "code that outputs a data structure" is that you can voluntarily choose to use no control flow. The tool takes declarative input, and optionally you can use imperative code to make the job of writing that input easier. That's very different from a tool that gives you helper functions for writing an imperative core. In that case you're always writing something that's full of control flow, and it's up to you to make sure you get all the state transitions to be consistent with each other.