Explaining programming paradigms to non-programmers?
Any advice on how to briefly explain the differents programming paradigms to non programmers ?
6 comments
I like to teach using analogies, but I don't know if there is a single analogy to fit all of them. And age of the intended audience might be important to know.
Essentially, programming is the communication of steps at a given level of abstraction.
You can give examples of how the command "open" is different, depending on whether you are dealing with a door, a book, or an app on their phone.
You can demonstrate giving commands at different levels of granularity (as different paradigms represent different world perspectives). For example, you can give them one-by-one instructions to open a door (stick out your arm, grab the handle, turn the handle, pull, etc.) vs. just saying "open the door".
The fine-grained controls can be applied to anything, but the operator may or may not know that the individual steps are all part of a single action. Likewise, "open the door" is a bundled-up set of commands, and are more concise, but it relies on the person knowing how to perform the action. "Open the combination lock" won't work unless the person already knows the combination. "Open the combination lock, and here is the combination" relies on the person knowing how to work the lock, but taking an argument. "Open the <insert something wild>" may not make sense, or may require specialized knowledge.
In other words, programming paradigms are simply different ways of bundling instructions.
Essentially, programming is the communication of steps at a given level of abstraction.
You can give examples of how the command "open" is different, depending on whether you are dealing with a door, a book, or an app on their phone.
You can demonstrate giving commands at different levels of granularity (as different paradigms represent different world perspectives). For example, you can give them one-by-one instructions to open a door (stick out your arm, grab the handle, turn the handle, pull, etc.) vs. just saying "open the door".
The fine-grained controls can be applied to anything, but the operator may or may not know that the individual steps are all part of a single action. Likewise, "open the door" is a bundled-up set of commands, and are more concise, but it relies on the person knowing how to perform the action. "Open the combination lock" won't work unless the person already knows the combination. "Open the combination lock, and here is the combination" relies on the person knowing how to work the lock, but taking an argument. "Open the <insert something wild>" may not make sense, or may require specialized knowledge.
In other words, programming paradigms are simply different ways of bundling instructions.
The only way to understand different programming paradigms is to learn a little bit about programming. If they insist on remaining "non programmers", i.e. determined not to know anything about programming, then there isn't much hope.
Otherwise, it's like asking how to explain the difference between manual and automatic to non-drivers, or the difference between VFR and IFR to non-pilots, or the difference between assets and liabilities to non-accountants, etc. One doesn't have to be an expert on the topic to grasp it, but one can't remain completely ignorant either.
Otherwise, it's like asking how to explain the difference between manual and automatic to non-drivers, or the difference between VFR and IFR to non-pilots, or the difference between assets and liabilities to non-accountants, etc. One doesn't have to be an expert on the topic to grasp it, but one can't remain completely ignorant either.
This still is more of a techincal talk, but going from imperitive to functional can be explained well by venkat: https://www.youtube.com/watch?v=E8G2ByTQzuY
What paradigms are we talking? Agile / waterfall / scrum etc are all different rituals/bureaucracies wrapped around the following recipe
1. Decide what to do
2. Do what you decided to do
3. Go back to 1
1. Decide what to do
2. Do what you decided to do
3. Go back to 1
If we're talking imperative/functional/OOO kind of thing, I'd go
Imperative programming: Tell the computer what to do step by step.
Procedural programming: Usurp the kingdom of the imperative, organize imperative halmets into fiefdoms. Call each one a "procedure".
OOO programming: Usurp the kingdom of the procedure. Gather the fiefdoms of procedures into a baronry called "Objects instantiated from Classes" where each object manages its own state and affairs.
Functional programming: Defeat the heresy of OOO! Changes to state should be strictly controlled from a single source of truth! Hack, slash, pew pew.
Imperative programming: Tell the computer what to do step by step.
Procedural programming: Usurp the kingdom of the imperative, organize imperative halmets into fiefdoms. Call each one a "procedure".
OOO programming: Usurp the kingdom of the procedure. Gather the fiefdoms of procedures into a baronry called "Objects instantiated from Classes" where each object manages its own state and affairs.
Functional programming: Defeat the heresy of OOO! Changes to state should be strictly controlled from a single source of truth! Hack, slash, pew pew.
letmechatgptthatforyou.com
but seriously, you might get something interesting from chatgpt
but seriously, you might get something interesting from chatgpt