All code is just some text. In the future all code may be English / French / Chinese in .md files, but the specific language is not relevant right now. Why then bother with Structured Programming, Object Oriented Programming, Functional Programming et c? It’s all going to be text translated to machine instructions anyway?
For the sake of humans and their context window.
Even if you were not writing code before the great democratisation, you will have encountered the pitfalls in some other writing. Code – whether it is written in Javascript or English – has to be quite specific, meaning you may refer to the same concept in many parts of the text. IF you write a sales pitch, a tender, a business plan et c you may encounter the same problem. You call a concept something on page 3, 7,8, and 11 – and then you need to rename it, and if you are lucky a Search/Replace will help you – but you may also end up renaming things that had nothing to do with what you were trying to rename because the start word was partially matched all over the rest of the document. Programming have loads of such problems. Most of the barriers built into programming languages and paradigms are there to let you scope your code so that the blast radius is smaller when you need to make changes.
The other thing that code struggles with is that it runs on a computer with shared resources (runtime storage in memory and long term storage on “disk”), and different parts of the code may access this shared state in uncontrolled ways, so programming languages and paradigms try to help programmers avoid creating chaos. Shared state is a thing that you cannot easily translate into the world of documents, but think of it as a shared whiteboard in the office where someone wrote down something important that you rely on for work and you check regularly. One morning someone changed that thing. Unless you keep a camera pointed at the whiteboard you’ll never know who changed it, and even if you did, it’s hard to know why unless they tell you.
The OOP way is that every object has its own whiteboard that nobody else gets to look at, functional programming solve the problem by replacing the whiteboard with an old fashioned flip chart and permanent markers, so that you cannot modify, only add.
The building blocks for this scoping exist within the languages to a varying degree but it is up to you how to use them. The paradigms exist to propose a common way to use the language tools in the most efficient way – in fact most commonly the paradigm was defined first, and then a language was constructed to provide the tools necessary. Some later languages offer tools that support multiple paradigms.
Like – in the Object Oriented paradigm, you bundle code and data together so that the rest of the system talks to a clean abstraction and does not know or care how that class (or rather the objects instantiated from the class) actually does its work. This lets you test the class independently and change the implementation without affecting the greater whole – if you design the code right. You could also break the encapsulation and make the inner data fully available to be manipulated by other classes, which defeats the purpose of OOP. You’re giving everyone access to read from your whiteboard, meaning they’ll start relying on your loose notes rather than the expected output of your work. If you break encapsulation, you are not writing object oriented code. The whiteboard in this case can be whatever – a local hard drive, a shared dropbox, a shared stripe account, a shared youtube account et c. If it can be accessed by everyone in the office of this allegory, it is a whiteboard.
Functional programming operates on a global state and values. Everything is on a flip chart. If you create a value it keeps existing forever (until it gets collected). Languages adapted for the functional paradigm has a bunch of tricks added which means that it can infer several complexities based on what ever is on the flip chart already, and the runtime layer that executes the code can do things like recursion (code calling itself) without running out of stack memory. These features let you write less code, more terse code, but also the compiler is very harsh and unrelenting when it comes to syntax. The code is so simple to read that if it compiles it is observably correct, but unless you work in it every day, getting the code to compile is a nightmare.
So – how do these paradigms help the humans? They let you make changes that cause least surprise. The goal is to let you focus on just the task at hand without needing to have anxiety that you are breaking the whole rest of the application. Unless you work in PHP when that anxiety never goes away. You will notice that keeping a small blast radius and a small context is not only good for human brains, they help AI agents as well. The better your code is, the stupider / cheaper models you can use to maintain your code.
OK, you say, I knew that – organising your code properly is better than some nasty mess. What is the right way to organise code?
That depends.
What does your application need to do today? If you can observe correctness, observe runtime state and easily make changes to the code, it is organised correctly. Today. The world might change. Your business might pivot. What happens then? Well – if your code was built correctly, you can safely change its architecture to meet future demands. Practically of course you can still encounter problems, but they are more likely to be human in nature. Teams that struggle to cooperate, meaning that gets lost between iteration et cetera, but that is beyond the scope of this blog.