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 push method 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...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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...