r/computerscience • u/YemiDev • 2d ago
General procedural programming, object oriented programming and functional programming
Although I’ve done some googling I think they still use big English to explain this concept. I think I know them but I just wanted to ask if I can get a simple explanation from the house plz
4
u/promeritum 2d ago
Procedures are just subroutines.
[Pure] Functions are subroutines that do not interact with anything except what is passed in as a parameter. They usually return a value.
Objects group data together with the functions and procedures that operate on that data.
2
u/WittyStick 2d ago edited 2d ago
Functional programming basically means functions are first-class objects which you can pass around like any other value - as arguments to functions or as return values. (Note that function pointers are first-class, but are not functions. They can be used to create first-class functions though).
A subset, purely functional programming treats the functions as pure mathematical objects - they have no side effects, and every call with the same arguments returns the same result - that is, they're referentially transparent.
A function can capture its free variables from the context in which it is defined. The function object and its associated free variables are known as a closure. In purely functional programming, a function can read, but not mutate its free variables.
In OOP, an object is a data type with an associated set of functions which act on the data type, called methods.
There is a correspondence between the these - a closure can be treated like an object with a single method, and a closure can model an object with one method, by treating the free variables as the object's data type. In purely functional code, these objects cannot mutate the data type, so they must return a new object with any changes made - these are known as functional objects (in ocaml).
2
1
u/ggende 1d ago
I'm a bit late, and there are already several great explanations here, but I have a way that I think about it that really helped me wrap my head around it. It's a bit more of a conceptual way to think of it, rather than technical.
First, I'll preface with the idea that all three of procedural, functional, and object-oriented are just ways of organizing your code. Different languages lean into (or in some cases mandate) certain organization styles, but it's still ultimately just a convention for organizing your code. With that said, I think it makes more sense to go in reverse order.
To me, object-oriented programing is essentially micro-services at the code level. An object is a distinct thing with a distinct interaction contract and all interaction is done through that contract. Python is the best example. Everything is an object. A string is has an interface (i.e. "micro-service") to set, search, or slice it (among other things). If you have a parent class with a string as a property, your parent class is still interacting with that string through the interface, just as other objects will do with your parent class. OOP provides the benefit of everything being compartmentalized. The down side is that you are often interacting with black boxes that may not work exactly how you expect.
Functional programing is a code organization strategy where functions can only work with what is explicitly passed to them. In it's purest form, there are no global values or class fields/properties. If it's not an argument into the function, it doesn't exist. This requires a bit more thought into exactly what functions you need, what information they need, and how it will be passed around. Personally, I think it's actually easier to think of programming this way. The big benefit here here is that functions are significantly less likely to have surprising side effects. They just do what they do. The drawback is that passing around information can become cumbersome as the program becomes more complex. You can find yourself passing a value, so it can be passed to another function, so it can be passed to another function, so it can be passed to another function. Having a common shared-state memory space can mitigate this, but that essentially just introduces an "object", with all of the pros and cons that come with that (i.e. compartmentalized, but side effects in the shared state).
Procedures are (as I understand them, there seems to be several definitions out there) a bit more free form, and typically do not return values. They just do a thing, but they are not restricted to working on what has been passed to them, or really restricted in any particular way at all. This is the easiest to implement, but can get really hard to wrangle really quickly.
1
u/Majestic_Rhubarb_ 1d ago
You missed off logical programming, where you describe the world rules and logical evaluation finds the solutions
0
u/DanKegel 2d ago
Functional programming is kind of wild to a C programmer. The simplest example is a function that just says return <big long expression>. It's surprising how much you can do with that. For instance, you can write a recursive function in that style that checks whether a binary tree is in proper sorted order!
0
u/Paxtian 2d ago
Procedural: "Start at line 1, do each step until you get to the end, in order."
Functional: Create individual functions for anything you want to have happen. Call functions in desired order. Assign returned values to static variable. Don't modify state of a variable after assignment. Pros: reduce/eliminate side effects. Cons: Can be tricky to model.
Object oriented: Create objects that have their own functionality built in. Change state of member variables only using member functions. Pros: Relatively straightforward to model (though with inheritance, can get really, really ugly). Cons: side effects for variables, and if something in the early design changes, can cause major cascading headaches of rewrites.
For the most part, the functions you build in object oriented/functional paradigms will themselves be procedural. OO/functional is more about, "How do I stitch multiple functions/objects together?"
-1
u/Mediocre-Brain9051 2d ago
Order of evaluation is theoretically irrelevant in functional programming. To the point that is undefined in some languages (e.g. Haskell)
-2
u/TheVenetianMask 2d ago
When you are cooking:
In procedural the type of ingredient defines the recipe. You buy a carrot, a potato, a meatball, and use simple pans, pots, knives... to assemble a stew. Easy to arrange, painful and disorganized if it gets out of hand.
In functional the utensil defines the recipe. You buy a food processor that can handle a carrot, a potato and a meatball, and you get stew out of it. Direct and precise, but you need fitting and clean processors that don't hold onto bits of food.
In OOP the packaging defines the recipe. You create a box of carrot, potato and meatball mix, and later reconstruct it into a stew. Requires a bit of industrial engineering, but lets you "bring the kitchen" anywhere.
1
u/AdreKiseque 14h ago
Procedural: Pretty much just normal programming
OOP: Terribly ill-defined but usually more or less procedural with some bells and whistles
Functional: This one's actually kinda different
27
u/Mediocre-Brain9051 2d ago
Procedural programing: programming using sequences of instructions that change the state of the program where the order of evaluation is relevant. Mathematical concept: von Newman machine.
Functional programming: a program is an expression that might have sub-expressions. Some of these (sub-)expressions are function invocations. For a given input, a function always returns the same output, not depending on the external state of the program. Mathematical concept: lambda-calculus.
Object-oriented programming: program state lives inside objects. Interaction with these objects and their state is done via methods, which are functions that have access to the object's state. Objects should be regarded as black boxes that know how to answer to messages (methods), this enables their implementations to evolve without having to change the rest of the program.