And perhaps, throw in why, as a 5-year-old, I will wanna use one over the other (if that makes any difference)
For further actions, you may consider blocking this person and/or reporting abuse
And perhaps, throw in why, as a 5-year-old, I will wanna use one over the other (if that makes any difference)
For further actions, you may consider blocking this person and/or reporting abuse
Aditya47x -
Jimmy Guerrero -
Jonathan Trevino -
Akash Singh -
Top comments (6)
The typical answer you'll get is "declarative programming is what, imperative programming is how". I'll expand on that a little bit: "declarative programming means describing what the end result should be, while imperative programming requires specifying the ordered steps needed to get there".
Benefits you get from declarative programming are largely in making code read more naturally. It allows for your code to visually convey structure and meaning. It allows for the entirety of the intent of some code to be described in one place. It allows a developer to spend less time parsing and instead jump right to the answer of "what does this code do?" It can also mean abstracting away the details of complex APIs behind a cleaner interface, letting someone else deal with the complexity of making sure everything is executed properly.
Admittedly this explanation still isn't great though. It makes a ton of sense if you already understand the concept, but leaves something to be desired as far as understanding how each paradigm is used and why. I think examples are likely the best way to clarify. Excuse me for the web-centric bent here - it's easiest for me to come up with on the spot, though the principles apply in other languages and scenarios.
A great use case is UIs. Compare the following:
The first one uses VueJS templating syntax (for sake of example), while the later uses jQuery. Right off the bat, I hope the first example is easier to read. But why?
h1
is above theul
, and theli
s are within theul
). That's a big one.list
variable changes (and it's able to help make sure that it's generally performant with less thought from the developer).Another example is when considering configuration. You can see this when comparing something like grunt (a task runner, simply executing commands in order) versus webpack (configuration driven, you describe what tools should handle what type of input, how you want the output formatted, what project-wide conventions to use for things like path aliases, etc). Another example would be an Infrastructure as Code tool like Terraform, where you describe, say, the type of servers you want and what their settings should be in a config file rather than making calls to an API. I can't immediately come up with a good concrete code example for this one, but a big benefit here is that often it means that you can say "here's what I want my system/process to produce, you go figure out how to get everything set up" without having to handle the details of doing it efficiently (eg with concurrency), disparate or complex APIs from various providers, or just generally doing as much work by hand.
A final interesting situation is functional programming. While I'm not personally a proponent of writing fully functional code, I do take advantage of many of FP's concepts because of their declarative nature. I do appreciate that functional programming is super intimidating if you haven't seen it before (it was for me!), and there are benefits to being explicit over terse. That said, once you get a grasp of it, there are great readability benefits because of this declarative nature. Take for example (evidently I haven't gotten to the refrigerated items yet):
Some distinct benefits of the latter approach:
let itemsToBuy = shoppingList.filter(item => !item.bought);
can be read as "itemsToBuy is (=
) the items of shoppingList (.filter
) where the item hasn't been bought (item => !item.bought
)". With the first approach, you can technically still do that, but it's not as natural - especially as with the second approach, the evaluation of the expression is directly assigned to the variable (as opposed to using an explicit "accumulator").for..of
removing the need to keep track of an array index too!), but there are situations where it can be a help.const
. The benefit here? The contents of the variable get declared exactly once. You don't have to go tracking down where it gets changed if you decide to adjust it later (or do it on accident), and it prevents you from reusing variables once their meaning changes.totalCost
, you first take the price of each item (themap
) and then add them together (thereduce
). This example might honestly be clearer with the imperative approach, but when you have a number of steps to get from point a to point b, it can be nice to have the explicit steps of translating your array from one state/meaning to another - where you tend to get into trouble is when steps get nested instead of chained. This is where I find the FP approach becomes quite opaque and doing it more imperatively can be clearer. Another approach is to split out the internal steps to individual assignments to separate variables.Hopefully this was a useful way of looking at it, if there's anything still left confusing I'd be happy to clarify. π
This is an interesting read and exhaustive. Thanks for sharing
I'm not sure how to understand this part. Does a framework cutting down on what I need to write in a way making me write "declarative programming" i.e "declarative programming means describing what the end result should be"? Because in the example of the UI between vue and jquery, the Vue abstracts the rendering of the template away, whereas the Jquery approach, one has to write it out.
In other words, behinds the scenes, the Vue abstraction that got the rendering of the li to happen would have be declarative or imperative?
Maybe I'm confused.
If I'm understanding your question correctly, yes, Vue's internals use imperative code so that consumers of the tool are able to stick to declarative code. This is much like a database engine - the operations required to execute your SQL query are calculated by the database engine and invisible to the user, but will naturally be implemented inside the engine in an imperative fashion. Somewhere in the pipeline you will always need to imperatively tell the computer what to do.
SQL is declarative. You tell SQL your intention:
How to best implement this? The nice thing is that you can mostly let SQL figure this out, merely giving him indications that you will use often this index to do searches.
Imperative programming is micro-management: do this, then do that, then do this, then do that.
If
Then ORMs are "Imperative"?
Nope, ORM are just a convenience wrapper to make SQL easier to use in your programming language, but apart from them pretty much the same.
If you were to create your own logic on how to fetch efficiently all users living in Berlin, that would be imperative.