Programming paradigms

These concepts were introduced in the first high level programming languages and can be considered cross-paradigm.

• variables give names to memory addresses or data structures
• scope and lifetimes for variables essentially means we can have variables which are local to a procedure, which can't be accessed globally
• parameters allow us to pass variables into a procedure when we call it
• compound data structures provide convenient implementations of things like arrays etc

If we strictly use these features as much as possible, and avoid global state, this does clearly help, for these reasons:

• when we see a local variable definition we immediately know it will not be accessible to any other code (unless it is passed to the code with a procedure call)
• we can tell what data each procedure will be using

However, it does not solve all of our problems. This is because:

• if there are lots of parts of your program that need to interact with a certain piece of data, you just end up passing it as a parameter to every single procedure call, making it defacto global
• our data is still mutable so given the previous point, we haven't solved anything

People make a big deal out of Object Oriented programming but I think it's often over-explained which makes it seem a lot more complicated than it is.

All you really need to understand is classes. Think of a class as a container which encapsulates data and behaviour together. A class contains:

• some private data structures which are not directly accessible outside the class
• some methods which are essentially procedures which are how other pieces of code interact with the class.

To put it in a single sentence it's a bag of procedures with cached data.

A class has an instantiation method which creates whatever internal data structures it has, and once it has been instantiated you have an object.

What problem does this solve? Well it allows us to control access to data. This is called Encapsulation. So for instance let's imagine we have a number but we want to ensure that it can only be incremented (not decremented) and it always has to be a prime number, we can make a class thus:

#!/usr/bin/env python3

class PrimeNumber:
    def __init__(self, start=2):
        """
        Initialize the class with a prime number.
        If the given number isn't prime, it will find the next prime number.
        """
        self.number = start
        while not self.is_prime(self.number):
            self.number += 1

    def is_prime(self, n):
        """Check if a number is prime."""
        if n < 2:
            return False
        for i in range(2, int(n**0.5) + 1):
            if n % i == 0:
                return False
        return True

    def view(self):
        """Return the current prime number."""
        return self.number

    def increment(self):
        """Increment the number to the next prime number."""
        self.number += 1
        while not self.is_prime(self.number):
            self.number += 1

This can be super useful as sometimes you do want to associate certain behaviour with certain data.

However I would argue it doesn't actually do anything to solve the structural problems with our code. This class's methods can still be called from dozens of different places in our code, so it's potentially just another form of globally mutable state.

Furthermore a disadvantage of using OO as a program design philosophy (like in Java where you use classes for everything) is that every class potentially contains state so you end up with state in dozens of different places which creates a lot of cognitive load trying to understand where everything is.

Like OO, the definition of Functional Programming has changed over the years and means different things to different people. But I am not giving a history lesson or writing an enormous book, rather trying to explain things concisely so they can be understood. So I will define it for you thusly:

In Functional Programming we simply never mutate data.

For instance:

• we do not re-assign variables, we just make new ones
• we do not add items to arrays. Rather we generate a new array which is a superset of the original.

Your procedures are now called functions, they (usually) take an input, and they return an output which is derived or modulated by the input. Please read about Pure functions.

It is important to emphasise that different paradigms are useful for different things and there is no one "best" paradigm.

I think the reason Object Oriented gets so much hate is because it's massively overused and ends up in places it really doesn't belong.

People act as if Functional Programming is an alternative to OO but I am perfectly happy to use a mixture of both in one program.

I think a good programmer understands all the paradigms and knows what is the best situation to use each. There is a good video about that here.

Also there is an enormous amount of overlap between different paradigms. Most programming languages that are used for app development are very cross-paradigm. According to Wikipedia Java is generic, object-oriented, functional, imperative, reflective and concurrent.

There are around 70 programming paradigms listed on the Wikipedia page about programming paradigms, but you don't have to learn all of them.

The most important paradigms I've missed out in this are probably Declarative Programming and Logic Programming. So researching those specifically may be a good idea.

IMO the most useful and accessible declarative languages are config management and IAC languages like Ansible and Terraform. You declare what result you want and the language figures out how to achieve it. These tools are designed for platform engineers rather than software engineers but if you plan to do any infrastructure work at-all you will find them useful.

Logic programming is used for solving mathematical and logic problems but isn't suitable for application development.

When I was talking about RAM and Global Mutable State earlier, one thing I didn't mention is that modern computers do have "memory protection" features to stop programs on a timesharing operating system accessing each-other's memory.

These features have been around since early mainframes from the 1960s.

I am very biased as I love functional programming, so I want to include some extra notes around that paradigm.