4 ms·
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 par
by 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 agoWhat 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 agoNope. Buggy declarative code is harder to debug than buggy imperative code.
- chousuke 5y agoI 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 agoYou 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.
- dnautics 5y agoRead beefwellingtons SQL EXPLAIN PLAN, comment. I've also watched my roommate have a four hour argument with her coworkers about one line in their kubernetes deployment[0]. I've also spent days trying to fix a declarative Ansible playbook, only to table flip and rewrite it from scratch in 20 minutes (this was a MySQL install-and-configure command where MySQL version had drifted underfoot). [0] iirc this was not a bug in their kubernetes operator (or maybe it was, I don't recall exactly) but a situation where they didn't understand why their containers were exhibiting the anti affinity properties they were expecting out of their declarations.
- 5y ago
- BeefWellington 5y agoThis is an often overlooked thing. Anyone who's had to do an EXPLAIN PLAN or equivalent to figure out why a SQL query is suddenly taking 40x the time to execute and return results can attest to this I think.