Learning to code is not easy when English is not your first language. It gets especially tough with all the vocabulary and expressions that you wouldn't usually encounter in everyday context. For me, one of such struggles has been remembering declarative and imperative programming — which one is which. I've read a couple of posts and definitions and while they made perfect sense, I'd have to google it again after half a year. ✨ This week, I finally found two mnemonics that work for me and I'm happy to share them in hope that they would work for you as well:
I'm also curious — how did you remember them? I heard that that's something even non-native speakers find confusing.
note: in this post I’m not going to explain the two programming styles — I’m just offering a mnemonic that helped me remember for good which one is which. If you want to understand the two styles better, check this great post on freecodecamp.
Mnemonic one: age of empires 🧙♂️
Imperative programming: the Romans!
The word 'imperative' sounds almost like the Latin imperium, which means empire. So, whenever I need to give an example of an imperative programming, I think about all the work that needs to be put into building a massive civilization — I think about the Romans and how they laid all the roads and built all the infrastructure and aqueducts. This feels awfully similar to DOM manipulation with vanilla JS or doing anything with C — it's the long way, oftentimes to some degree from scratch.
Declarative programming: Byzantines, Angles, Saxons, and Franks!
Okay, the sun has set on the Roman Empire, other folks arrive on these lands, look around, think that these roads and baths are quite okay, maybe they just change the city name road sign and declare it theirs. That's React, which is based on delightful abstractions.
Mnemonic Two: Birthday cake 🎂
Imperative programming: baking!
It's your best friend birthday. You make a Pavlova cake because you know they love it. Baking itself takes like 5h but you also need to go get all the ingredients and then clean the kitchen afterwards. Easily, 7 hours of work. This is how it feels to do DOM Manipulation with vanilla JS or do anything with C — it's the long way, oftentimes to some degree from scratch.
Declarative programming: plate with a cake
Now, imagine some dude comes late to the party and everything is prepared and he didn't bring anything. Someone asks him what he's brought, he rushedly grabs a plate and puts a piece of cake you baked and hands it to the person without much chit-chat — the person seems really happy with what they got! Having this piece of cake in their hands, they don't care much about the process of its creation. That's React, using what's already there and making it easy and fuss-free to get what you want. You may, however, later learn that in the process of the cake creation a bunch of strawberries were used and you are awfully allergic to all berries but didn't think to ask ¯_(ツ)_/¯
Cover photo by by Aline Poncefrom Pixabay
Body image by ERIND DERSTILA from Pexels
Top comments (4)
You haven't really described the difference between the 2 styles very well. An excellent explanation can be found here - freecodecamp.org/news/imperative-v...
Hey Jon!
Thank you for this link — it still does not solve the problem at hand: I do understand what each one is, it’s just the names that in half a year will again be confusing.
As I’m saying in the first paragraph, my intention was not to explain what each one is exactly but to come up with a mnemonic that will help me remember in half a year which definition and which example belongs to which name. It’s not the definition that’s problematic to me, it’s the two words (“imperative” and “declarative”) that just are confusing because in some other languages they mean the opposite of what the definition would indicate.
How mnemonic works is you build story/association, which very loosely connects to the word and then you find a way to connect it with an example. I’m doing so, you need to know what eg React is, vanilla JS, C, and you should know what the two programming styles here are. For example, when teaching English to kids, I was shown the image of an aunt standing on the rooftop holding a TV antenna — surprisingly, many kids do have problems with the word “aunt” but not “uncle”, and antenna is a word that exists is many languages. This mnemonic does not explain who the aunt is, it helps you just remember the word.
Also, I’m linking the free code camp article — l moved it now to a separate paragraph so the folks won’t miss it and won’t have to google it like you did (I don’t suppose you copied that link from my blog post just to troll, did you?)
I can't speak to their intent (about trolling), but I sort of disagree that the linked FCC article is an exemplary explanation. ...Or maybe it's overkill to get into a discussion of declarative approaches arising naturally as a consequence of abstractions (in either OOP or FP) to deal with the potential for side effects. I mean, the FCC article also uses a declarative
pushmethod in its imperative example. Not a huge faux pas, but along with comments like "imperative programming being easy to reason what it does" (hint: this quickly becomes not true), it makes me question whether the author even knows the weaknesses in the message it's imparting to folks increasing their understanding. So, thanks OP for putting this out there & not backing down.Thanks for this thought! I think this is a part of why this subject is confusing to new programmers, along with the nomenclature that just doesn't make sense linguistically.
Coincidentally, I actually am going through Kent C. Dodd's course now and I just noticed that he linked an article that seems really great in both explaining the imp/dec approaches and using plain English — I'd be curious what you think about it, @imkleats : ui.dev/imperative-vs-declarative-p...