3 ms·

I know the difference, why it's implicitly assumed to be better is what eludes me. In my experience, describing the end result in a way the program understands

by carlmr 5y ago

I know the difference, why it's implicitly assumed to be better is what eludes me. In my experience, describing the end result in a way the program understands is sometimes much harder than telling the program "do this". Don't get me wrong I think the longevity of SQL shows that declarative can be the right way. However I think there's a logical leap with declarative = better.

halpert 5y ago
Declarative is better because it’s simpler. For instance let’s say you have a system and you want to add a new resource to it. If you’re using an imperative paradigm, then you’ll write a script to transition the state from the current state to the desired state. Now let’s say you want to spin up a new cluster in a different region, you need to write another script to go from the empty state to your final state from before. With a declarative paradigm, both modifying and creating resources are the same. It’s also easier to understand the current state of the system. In an imperative style, you need to understand every operation that has been performed to know what the current state is. In a declarative system, you just need to look at the most recent declaration. In short, declarative is more scalable and understandable. Another way to look at your question is to ask what is better about the imperative style? Having used both, I can’t think of any advantages. Maybe you could say you have more control with imperative, but is that control really necessary? In my experience, it is not. The additional control just makes things more complex. And of course you can make a overly complex, hard to understand system using a declarative paradigm. But the simplest declarative system can be simpler than the simplest imperative system for achieving the same configuration.
- dnautics 5y ago
  > declarative is more scalable and understandable. If you don't have to debug your system in the large (why is my outcome not what I expect) If your operators are written correctly and you don't have to debug your system in the small
  - halpert 5y ago
    What you’re saying is equivalent to “buggy declarative code is harder to debug than working imperative code.” Obviously that’s true, but not exactly a convincing argument that imperative is better than declarative. Your underlying assumption is that it’s easier to write correct imperative configuration than it is to write correct declarative configuration. In my experience, this is not the case. Consider a basic task like provisioning a fleet of hosts and deploying some code to the fleet. In an imperative approach, you need two distinct steps. One for provisioning, and one for deploying. Both operations are multi-step processes that are required to be idempotent because the number of possible failures between the start of provisioning and the end of deployment is quite large. It’s not easy to write a system that does this, as there are a lot of steps that need to be enumerated via imperative scripts for both provisioning and deployment, and it’s even harder to do in a failure tolerant way. Compare the above to a Kubernetes deployment. The entire configuration is 30 lines of yaml. There is no providing step. Kubernetes will make sure the resources you need are provisioned and it will do so in a failure tolerant way.
    - dnautics 5y ago
      Nope. Buggy declarative code is harder to debug than buggy imperative code.
      - chousuke 5y ago
        I think the core thing is that if you have a bug in the declarative code, it usually affects everything and can be fixed in the execution engine, or you didn't actually declare what you wanted but something else. By contrast, bugs in imperative code can manifest simply because you happened to write it in such a way that relied on some assumption that no longer holds and your imperative code does something it should not do because its preconditions are invalid. Declarative approaches are generally more robust because they by necessity tend to be designed to handle more diverse initial states and still reach the correct result.
      - halpert 5y ago
        You still are implicitly assuming it’s easier to write bug-free imperative configuration compared to declarative. It doesn’t really matter which is harder to debug if it’s much easier to write bug-free code using declarative code. Again, some specific examples that underpin your assumption would be helpful in making your argument more convincing.
ZukoBestGirl 5y ago
You not liking it is a "you problem". The reason people keep insisting that declarative is better, is because it just is. Assume a program that is much better than you can ever hope to be at optimization at compile time. A real AI, much more intelligent than you and any other human being could ever be. Would you still describe the minutia of how you want to do things? Knowing full well it won't do that. And will chose a better option. Or would you just tell it what you want to be done, and not care about how it achieves this? If it can achieve whatever you want to be done, is it not more logical, natural, and human to just describe what you want the end result to be? The answer is an unequivocal "yes". You've already received the answer. Here in this thread, but also, I'm guessing a great many times. You just refuse to accept it. As I've said, "a 'you' problem".
lordnacho 5y ago
You're right, it isn't always better. But generally in a lot of problems these days we already have a load of generic methods for the implementations, and you just want to specify the end result. There's enough resources that we don't care how the thing is done, the engine will probably do it in an acceptable manner, so you save a lot of code just telling it what you want. It's really just a preference for convenience over control.

by carlmr 5y ago

halpert 5y ago

Declarative is better because it’s simpler. For instance let’s say you have a system and you want to add a new resource to it. If you’re using an imperative paradigm, then you’ll write a script to transition the state from the current state to the desired state. Now let’s say you want to spin up a new cluster in a different region, you need to write another script to go from the empty state to your final state from before. With a declarative paradigm, both modifying and creating resources are the same. It’s also easier to understand the current state of the system. In an imperative style, you need to understand every operation that has been performed to know what the current state is. In a declarative system, you just need to look at the most recent declaration. In short, declarative is more scalable and understandable. Another way to look at your question is to ask what is better about the imperative style? Having used both, I can’t think of any advantages. Maybe you could say you have more control with imperative, but is that control really necessary? In my experience, it is not. The additional control just makes things more complex. And of course you can make a overly complex, hard to understand system using a declarative paradigm. But the simplest declarative system can be simpler than the simplest imperative system for achieving the same configuration.

dnautics 5y ago
> declarative is more scalable and understandable. If you don't have to debug your system in the large (why is my outcome not what I expect) If your operators are written correctly and you don't have to debug your system in the small
- halpert 5y ago
  What you’re saying is equivalent to “buggy declarative code is harder to debug than working imperative code.” Obviously that’s true, but not exactly a convincing argument that imperative is better than declarative. Your underlying assumption is that it’s easier to write correct imperative configuration than it is to write correct declarative configuration. In my experience, this is not the case. Consider a basic task like provisioning a fleet of hosts and deploying some code to the fleet. In an imperative approach, you need two distinct steps. One for provisioning, and one for deploying. Both operations are multi-step processes that are required to be idempotent because the number of possible failures between the start of provisioning and the end of deployment is quite large. It’s not easy to write a system that does this, as there are a lot of steps that need to be enumerated via imperative scripts for both provisioning and deployment, and it’s even harder to do in a failure tolerant way. Compare the above to a Kubernetes deployment. The entire configuration is 30 lines of yaml. There is no providing step. Kubernetes will make sure the resources you need are provisioned and it will do so in a failure tolerant way.
  - dnautics 5y ago
    Nope. Buggy declarative code is harder to debug than buggy imperative code.
    - chousuke 5y ago
      I think the core thing is that if you have a bug in the declarative code, it usually affects everything and can be fixed in the execution engine, or you didn't actually declare what you wanted but something else. By contrast, bugs in imperative code can manifest simply because you happened to write it in such a way that relied on some assumption that no longer holds and your imperative code does something it should not do because its preconditions are invalid. Declarative approaches are generally more robust because they by necessity tend to be designed to handle more diverse initial states and still reach the correct result.
    - halpert 5y ago
      You still are implicitly assuming it’s easier to write bug-free imperative configuration compared to declarative. It doesn’t really matter which is harder to debug if it’s much easier to write bug-free code using declarative code. Again, some specific examples that underpin your assumption would be helpful in making your argument more convincing.

ZukoBestGirl 5y ago

You not liking it is a "you problem". The reason people keep insisting that declarative is better, is because it just is. Assume a program that is much better than you can ever hope to be at optimization at compile time. A real AI, much more intelligent than you and any other human being could ever be. Would you still describe the minutia of how you want to do things? Knowing full well it won't do that. And will chose a better option. Or would you just tell it what you want to be done, and not care about how it achieves this? If it can achieve whatever you want to be done, is it not more logical, natural, and human to just describe what you want the end result to be? The answer is an unequivocal "yes". You've already received the answer. Here in this thread, but also, I'm guessing a great many times. You just refuse to accept it. As I've said, "a 'you' problem".

lordnacho 5y ago

You're right, it isn't always better. But generally in a lot of problems these days we already have a load of generic methods for the implementations, and you just want to specify the end result. There's enough resources that we don't care how the thing is done, the engine will probably do it in an acceptable manner, so you save a lot of code just telling it what you want. It's really just a preference for convenience over control.