Hi Arjun!

This is a great question! In my opinion, the answer here should be treated as subjective rather than strictly theoretical. Anyway, let me try to clarify a few terms that should help to understand the concepts of procedural programming and object-oriented programming better.
First, let's start by explaining what the term programming paradigm means.
A programming paradigm is a model, or a pattern, which we use to classify programming languages according to their features.
There are two main contrasting sets of paradigms - imperative paradigms, and declarative paradigms.
Imperative paradigms represent computer programming in which the program (by using statements) describes the steps that need to be executed in order to change the program's state. Thus, the imperative paradigm is about creating a pattern that aims at describing how a program should operate.
In contrast to that, declarative paradigms refer to those paradigms where the statements (i.e. the computer programs) do not describe the steps that need to be executed in order to change the program's state.
Thus, the computational logic is not presented in a step-by-step fashion as it happens with imperative paradigms. Here, the focus is on the result, as opposed to describing how a program should operate.
Having made this distinction, stick to imperative paradigms for now.
A subset of these imperative paradigms is the structured programming. It is characterised by further improving the clarity and quality of the code which uses detailed control flow constructs to execute the intended operation. These constructs are the well-known if/then/else statements, for- and while- loops, and more.
Derived from structured programming is the procedural programming paradigm. This paradigm represents routines/subroutines/functions, which designate a series of computational steps that need to be executed in order to change the program's state. Important to add here is that a given procedure can be called (or invoked, or referred to) at a specified-by-the-programmer moment during a program's execution.
Moreover, in procedural programming, a program consists of two parts, so to speak: 1) data, and 2) modules/procedures/functions that operate on the data. So, the concepts 1) and 2) are separated. Thus, the focus here remains dividing the program into functions.
Object-oriented programming is still a form of imperative paradigm, however, this time 1) and 2) are treated as a single entity. Namely, this is the entity that is called an object, which typically is an instance of a class which encapsulates data (i.e. fields) and the corresponding procedures (called methods). A great feature of these objects is that their procedures (i.e. their second component), can access and often modify the data (i.e. their first component).

Now that we've established the main difference between procedural programming (let me call it PP for brief) and object-oriented programming (OOP), here's a short list that briefly compares some of their features. Note that these differences can sound quite theoretical or abstract at this stage, but can surely become intuitive once you advance with coding in any of these types of paradigms.

In PP, programs are divided into functions. in OOP, they are divided into objects.
PP uses a top-down approach, while OOP - a bottom-up approach.
Adding new data is not easy with PP, and is easy with OOP.

Don't forget that today, languages are typically multi-paradigm, in the sense that they are a mixture of different paradigms. However, a language is usually centred around one main paradigm, or approach, that will be associated to best performance and code legibility. Then, it can have features that normally relate to other paradigms.
To conclude, let me say that especially after gaining a few years of experience, programmers may develop a more subjective way of interpreting some or all of the aforementioned terms. Nevertheless, I hope this entire explanation helps in building a framework that can serve as a point of reference in case you encounter these terms in the relevant literature.
In any case, the most important take-away from this explanation should be that paradigms are needed to shape a programmer's thinking in a way that they can improve the performance and legibility of the code they write, regardless of the language they use. I also hope that such a framework can help you more easily understand key features about procedural programming (and other paradigms).

I'd love to hear what others can add to improve this discussion, actually. Thanks for initiating it, Arjun!
Hope this helps.
Best,
Martin

Procedural Programming

Submit an answer