A new way to think

<aside> <img src="/icons/globe_lightgray.svg" alt="/icons/globe_lightgray.svg" width="40px" /> You need to unlearn concepts you are familiar with.

</aside>

Programming languages like real languages have sets of rules you follow in order to form coherent sentences (sets of instructions) in order to communicate (with the underlying hardware). However you might be thinking languages mostly differ in syntax and also have key difference in features for example Java has garbage collector and compiles to byte code before machine code whilst C directly compiles to machine code and some languages (like python) are interpreted. This is true in most cases but the way we actually structure and build the code is where programming paradigms come in.

Programming Paradigms

This image is from a youtube video which will be referenced somewhere below.

Programming paradigms are not to do with the language per say, although some languages enforce rules to “encourage” or “force” you to code in a specific way. Think of it like the philosophy behind the approach to building something and you have a set of tools to do it with, a good analogy is working out: we both want to train to gain muscle for example but you believe in a Arnold style high volume training with moderate to low intensity whilst I believe in a Dorian Yates style HIT workout where I focus on low volume but very high intensity. Now my gym might help me do that be reducing the number of equipment to help me prevent from doing to much volume or close the gym every other day, whilst yours does the opposite. Regardless of the environment we still do the same thing and achieve the same result but with different trade offs.

Untitled

Now going back to programming we can think of the way we design our code as the philosophy, from conceptualizing an idea how do we bring it to life with code and what is the best approach in doing this. This is where the various programming paradigms come in, now since I am no expert in any or all of these I will simply talk about the two that apply to us - imperative and declarative programming.

There are many different paradigms with sub categorized approaches from reactive to reflective to whatever. But there are two main branches which are relevant to us:

Imperative

The “how” as everyone else says - the main focus for us will be OOP (object oriented programming)

Declarative

The “what” as everyone else says - the main focus for us will be functional programming

See this embed if you are bored enough to learn about the other paradigms.

It is worth mentioning except in a few cases that we do not need to be strict on selecting a paradigm and in fact many languages allow you to do a mixture of paradigms in combination (and you should do this) so they are not mutually exclusive as you will see later but as an example you can have OOP with Procedural paradigms in one place.

Imperative vs Declarative (The Baker Analogy)

Imperative programming is like meticulously following a recipe to bake a cake. You control every step, making adjustments as needed. Declarative programming, on the other hand, is like ordering a cake from a baker. You specify the desired outcome, and the baker uses their expertise (often based on functional programming principles) to consistently produce the cake you want. While the declarative approach hides the details, there's still an underlying imperative process happening in the kitchen.

The approach you are most use to as most programmers are (unless you where a mathematician at university and had to use something like Haskell) is the imperative paradigm. Let us build some analogies to really understand what's going on.

Untitled

Imperative Programming

(The Recipe):

You are the baker: You carefully follow a detailed recipe, executing each step precisely.
Focus on the "how": You control every detail - measuring ingredients, mixing, beating, baking - and the order in which you do them.
Flexibility: If you want to tweak the cake, you modify the recipe itself, adding or removing steps, changing ingredients, or adjusting the baking time.

Declarative Programming

(The Order):

You are the customer: You tell the baker what kind of cake you want – a classic Victorian sponge.
Focus on the "what": You specify the desired outcome (the cake's characteristics), not the steps involved in making it.
Consistency: The baker uses their expertise and a known recipe to produce the cake. No matter how many times you order the same cake, you'll get a consistent result.

Contents