Does procedural programming have any advantages over OOP?

Question

[Edit:] Earlier I asked this as a perhaps poorly-framed question about when to use OOP versus when to use procedural programming - some responses implied I was asking for help understanding OOP. On the contrary, I have used OOP a lot but want to know when to use a procedural approach. Judging by the responses, I take it that there is a fairly strong consensus that OOP is usually a better all-round approach but that a procedural language should be used if the OOP architecture will not provide any reuse benefits in the long term.

However my experience as a Java programmer has been otherwise. I saw a massive Java program that I architected rewritten by a Perl guru in 1/10 of the code that I had written and seemingly just as robust as my model of OOP perfection. My architecture saw a significant amount of reuse and yet a more concise procedural approach had produced a superior solution.

So, at the risk of repeating myself, I'm wondering in what situations should I choose a procedural over an object-oriented approach. How would you identify in advance a situation in which an OOP architecture is likely to be overkill and a procedural approach more concise and efficient.

Can anyone suggest examples of what those scenarios would look like?

What is a good way to identify in advance a project that would be better served by a procedural programming approach?

Lyrism

this question troubles me because I want to say OOP.. but if you are so unsure that you would ask this question, and you take the OOP advice, youll probably knock out some procedural code pretending to be OOP – Greenman

@theman Hit it right on the head. OO is the recommended method for almost any situation, but if you don't understand it, you will just do more harm than good. – Trolley

You said that the Perl program seemingly was just as robust. Language flame war here from me, but I can't see Perl as being maintainable by any average programmer. Projects written by experts should be written so that average programmers can maintain them. – Frizzle

Was his solution strictly procedural? You can write OO code in Perl 5.8 – Fluorocarbon

This makes me wonder why he rewrote it. Alot of non-OOP developers use "if it aint broke don't fix it" to fight against refactoring into OOP. That maxim thrown aside in this case... – Russi

Answer 1

I would suggest using the most concise, standards-based approach that you can find for any given problem. Your colleague who used Perl demonstrated that a good developer who knows a particular tool well can achieve great results regardless of the methodology. Rather than compare your Java-versus-Perl projects as a good example of the procedural-versus-OOP debate, I would like to see a face-off between Perl and a similarly concise language such as Ruby, which happens to also have the benefits of object orientation. Now that's something I'd like to see. My guess is Ruby would come out on top but I'm not interested in provoking a language flame-war here - my point is only that you choose the appropriate tool for the job - whatever approach can accomplish the task in the most efficient and robust way possible. Java may be robust because of its object orientation but as you and your colleague and many others who are converting to dynamic languages such as Ruby and Python are finding these days, there are much more efficient solutions out there, whether procedural or OOP.

Germen

Answer 2

I like Glass' rules of 3 when it comes to Reuse (which seems to be what you're interested in).

1) It is 3 times as difficult to build reusable components as single use components
2) A reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library

From this I think you can extrapolate these corollaries

a) If you don't have the budget for 3 times the time it would take you to build a single use component, maybe you should hold off on reuse. (Assuming Difficulty = Time)
b) If you don't have 3 places where you'd use the component you're building, maybe you should hold off on building the reusable component.

I still think OOP is useful for building the single use component, because you can always refactor it into something that is really reusable later on. (You can also refactor from PP to OOP but I think OOP comes with enough benefits regarding organization and encapsulation to start there)

Falk

Looks like an interesting book – Kursk

and how many times more difficult is it to change several single-use component into standardized reusable components? – Tallbott

procedural is not always equivalent to single-use, and object oriented is not always equivalent to reusable. you can stuff procedural code into an object method or class method and have it be single-use. Then when you are ready to make it multi use after 3 or so uses, the "wrapping" has already been done, and you can just split methods, swap a variable for an instance variable, etc. It's like having a few steps lead start off of first base when you're about to take 2nd.. maybe you will, maybe you won't, but it's still best to take a few steps out. – Tallbott

Answer 3

Those who religiously support OOP don't have any facts to justify their support, as we see here in these comments as well. They are trained (or brain washed) in universities to use and praise OOP and OOP only and that is why they support it so blindly. Have they done any real work in PP at all? Other then protecting code from careless programmers in a team environment, OOP doesn't offer much. Personally working both in PP and OOP for years, I find that PP is simple, straight forward and more efficient, and I agree with the following wise men and women:

(Reference: http://en.wikipedia.org/wiki/Object-oriented_programming):

A number of well-known researchers and programmers have criticized OOP. Here is an incomplete list:

• Luca Cardelli wrote a paper titled “Bad Engineering Properties of Object-Oriented Languages”.

• Richard Stallman wrote in 1995, “Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program.”

• A study by Potok et al. has shown no significant difference in productivity between OOP and procedural approaches.

• Christopher J. Date stated that critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP. A theoretical foundation on OOP is proposed which uses OOP as a kind of customizable type system to support RDBMS.

• Alexander Stepanov suggested that OOP provides a mathematically-limited viewpoint and called it “almost as much of a hoax as Artificial Intelligence” (possibly referring to the Artificial Intelligence projects and marketing of the 1980s that are sometimes viewed as overzealous in retrospect).

• Paul Graham has suggested that the purpose of OOP is to act as a “herding mechanism” which keeps mediocre programmers in mediocre organizations from “doing too much damage”. This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques.

• Joe Armstrong, the principal inventor of Erlang, is quoted as saying “The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”

• Richard Mansfield, author and former editor of COMPUTE! magazine, states that “like countless other intellectual fads over the years (“relevance”, communism, “modernism”, and so on—history is littered with them), OOP will be with us until eventually reality asserts itself. But considering how OOP currently pervades both universities and workplaces, OOP may well prove to be a durable delusion. Entire generations of indoctrinated programmers continue to march out of the academy, committed to OOP and nothing but OOP for the rest of their lives.” and also is quoted as saying “OOP is to writing a program, what going through airport security is to flying”.

Barrier

I've programmed many projects using both OOP and non-OOP languages and approaches. I think the biggest problem associated with OOP stem from the failure of Java and languages derived from it to distinguish between values, unshared holders of values, and entities. OOP systems are far nicer than procedural ones when dealing with entities; not everything is an entity, though, and the strong design bias toward entities can make them less efficient when working with values and unshared value-holders. – Benzene

I think the biggest problem associated with OOP is that not a lot of people actually know how to use it. You don't just shove procedural code in classes. It looks like OP has a chip on his shoulder for OOP because he can't actually do it properly. To say that OOP is worse off in most situations when compared to procedural is rather laughable. – Prichard

Excellent answer. I personally think OOP is one of the most expensive mistakes in programming history. Having worked with it most of my career but seen functional programming (even in Java), I would just give OOP the could shoulder if it were up to me. Like you say, it helps mediocre programmers consider organization more at the expense of slowing 100x developers down from doing things more elegantly and correctly. Most programmers don't really know when to compose and decompose objects correctly. – Philoctetes

100% agree. In the end, computers are built of processors and RAM. If you load objects and write longer code - it costs more. Object Oriented programming is resource consuming and messy. OO made sense when compilation took days and you had to recycle compiled objects taking into account that you save time but lose storage. It does noit make sense today, and especially not with interpreter languages like php – Rader

Answer 4

Reusability (or lack of it) is not bound to any specific programming paradigm. Use object oriented, procedural, functional or any other programming as needed. Organization and reusability come from what you do, not from the tool.

Mendelsohn

Indeed: this is the main concept behind the Unix philosophy: small, well-designed programs that work together. – Sparkman

Answer 5

You gave the answer yourself - big projects simply need OOP to prevent getting too messy.

From my point of view, the biggest advantage of OOP is code organization. This includes the principles of DRY and encapsulation.

Ribald

What does DRY stand for? I searched up on Google but didn't find anything useful. – Sprain

That is not unique to OOP. It is true of any language that has modules and data hiding. And that includes C which is not even remotely OO. – Alarmist

finnw, yes, but OOP takes these ideas to a far higher level. – Ribald

I agree OOP almost forces programmers to organize their code more logically. I'll caveat that by saying that the Oracle Database Kernel (several million lines of code) is written in C. – Philoctetes

Most of the OO applications which I looked at their code, looks like a messy mash of thousands of files... wordpress, matomo, own cloud, roundcube, drupal,... it seems like OO is using the file system structure what creates a big mess – Rader

Answer 6

I think DRY principle (Don't Repeat Yourself) combined with a little Agile is a good approach. Build your program incrementally starting with the simplest thing that works then add features one by one and re-factor your code as necessary as you go along.

If you find yourself writing the same few lines of code again and again - maybe with different data - it's time to think about abstractions that can help separate the stuff that changes from the stuff that stays the same.

Create thorough unit tests for each iteration so that you can re-factor with confidence.

It's a mistake to spend too much time trying to anticipate which parts of your code need to be reusable. It will soon become apparent once the system starts to grow in size.

For larger projects with multiple concurrent development teams you need to have some kind of architectural plan to guide the development, but if you are working on your own or in small cooperative team then the architecture will emerge naturally if you stick to the DRY principle.

Another advantage of this approach is that whatever you do is based on real world experience. My favourite analogy - you have to play with the bricks before you can imagine how the building might be constructed.

Lunna

Answer 7

I think you should use procedural style when you have a very well specified problem, the specification won't change and you want a very fast running program for it. In this case you may trade the maintainability for performance.

Usually this is the case when you write a game engine or a scientific simulation program. If your program calculate something more than million times per second it should be optimized to the edge.

You can use very efficient algorithms but it won't be fast enough until you optimize the cache usage. It can be a big performance boost your data is cached. This means the CPU don't need fetch bytes from the RAM, it know them. To achieve this you should try to store your data close to each other, your executable and data size should be minimal, and try using as less pointers as you can (use static global fixed sized arrays where you can afford).

If you use pointers you are continuously jumping in the memory and your CPU need to reload the cache every time. OOP code is full of pointers: every object is stored by its memory address. You call new everywhere which spread your objects all over the memory making the cache optimization almost impossible (unless you have an allocator or a garbage collector that keeps things close to each other). You call callbacks and virtual functions. The compiler usually can't inline the virtual functions and a virtual function call is relatively slow (jump to the VMT, get the address of the virtual function, call it [this involves pushing the parameters and local variables on the stack, executing the function then popping everything]). This matters a lot when you have a loop running from 0 to 1000000 25 times in every second. By using procedural style there aren't virtual function and the optimizar can inline everything in those hot loops.

Bureau

Answer 8

I think the suitability of OOP depends more on the subject area you're working in than the size of the project. There are some subject areas (CAD, simulation modeling, etc.) where OOP maps naturally to the concepts involved. However, there are a lot of other domains where the mapping ends up being clumsy and incongruous. Many people using OOP for everything seem to spend a lot of time trying to pound square pegs into round holes.

OOP has it's place, but so do procedural programming, functional programming, etc. Look at the problem you're trying to solve, then choose a programming paradigm that allows you to write the simplest possible program to solve it.

Rainger

If you don't mind, I wonder if you could you edit your response to give an example of a situation where OOP might be incongruous? I would be very curious to hear your arguments on that. – Lyrism

Answer 9

If the project is so small that it would be contained within one class and is not going to be used for very long, I would consider using functions. Alternatively if the language you are using does not support OO (e.g. c).

Dorian

Answer 10

"The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” —Joe Armstrong

Do you want the jungle?

Mispleading

if you're building a jungle, yeah. if you just want the banana, no. how often do you need just the banana? implicit environment carried around is not a problem limited to OO. procedural has it too. and it's worse because it's not encapsulated. Touch one thing and you don't know how far reaching the change will potentially be. – Tallbott

Answer 11

Procedural programs can be simpler for a certain type of program. Typically, these are the short script-like programs.

Endospore

Answer 12

Consider this scenario: Your code is not OO. You have data structures and many functions throughout your progam that operate on the data structures. Each function takes a data structure as a parameter and does different things depending on a "data_type" field in the data structure.

IF all is working and not going to be changed, who cares if it's OO or not? It's working. It's done. If you can get to that point faster writing procedurally, then maybe that's the way to go.

But are you sure it's not going to be changed? Let's say you're likely to add new types of data structures. Each time you add a new data structure type that you want those functions to operate on, you have to make sure you find and modify every one of those functions to add a new "else if" case to check for and add the behavior you want to affect the new type of data structure. The pain of this increases as the program gets larger and more complicated. The more likely this is, the better off you would be going with the OO approach.

And - are you sure that it's working with no bugs? More involved switching logic creates more complexity in testing each unit of code. With polymorphic method calls, the language handles the switching logic for you and each method can be simpler and more straightforward to test.

Ambala

I think you can implement a quite maintainable switching logic using callbacks. This can be very flexible. But it isn't secure enough. – Bureau

Answer 13

The two concepts are not mutually exclusive, it is very likely that you will use PP in conjunction with OOP, I can't see how to segregate them.

Jamnes

Maybe you mix up "procedural" and "imperative"? – Rebak

Yea, I don't like how this question is positive. You can obviously mix the two, but I don't see any reason why you would unless OO was something you were fixing your code to be after the fact. Scary! – Trolley

Answer 14

I believe Grady Booch said once that you really start to benefit a lot from OOP at 10000+ lines of code.

However, I'd always go the OO-way. Even for 200 lines. It's a superior approach in a long term, and the overhead is just an overrated excuse. All the big things start small.

Specs

>10kloc you need to start managing the complexity, which is what OO is for – Russi

Answer 15

One of the goals of OOP was to make reusability easier however it is not the only purpose. The key to learning to use objects effectively is Design Patterns.

We are all used to the idea of algorithms which tell us how to combine different procedures and data structures to perform common tasks. Conversely look at Design Patterns by the Gang of Four for ideas on how to combine objects to perform common tasks.

Before I learned about Design Patterns I was pretty much in the dark about how to use objects effectively other than as a super type structure.

Remember that implementing Interfaces is just as important if not more important than inheritance. Back in the day C++ was leading example of object oriented programming and using interfaces are obscured compared to inheritance (virtual functions, etc). The C++ Legacy meant a lot more emphasis was placed on reusing behavior in the various tutorials and broad overviews. Since then Java, C#, and other languages have moved interface up to more a focus.

What interfaces are great for is precisely defining how two object interact with each. It is not about reusing behavior. As it turns out much of our software is about how the different parts interact. So using interface gives a lot more productivity gain than trying to make reusable components.

Remember that like many other programming ideas Objects are a tool. You will have to use your best judgment as to how well they work for your project. For my CAD/CAM software for metal cutting machines there are important math functions that are not placed in objects because there is no reason for them be in objects. Instead they are exposed from library and used by the object that need them. Then there is are some math function that were made object oriented as their structure naturally lead to this setup. (Taking a list of points and transforming it in on of several different types of cutting paths). Again use your best judgment.

Spectrohelioscope

Your choice of language partially determine which design patterns are going to be helpful to know, fwiw. – Symphonia

I think of interfaces being very much about reusing behavior. But the focus is on reusing the calling behavior (which does not change) vs. reusing the code that is called (whose implementation can be changed). Also - if you look at the GoF patterns, they tend to be very much about code reuse: Adding some additional level of indirection so you can change some things without affecting other things (so those other things can be reused w/o modificiation). Or adding some adapter level so you can reuse something in a new way. – Ambala

Answer 16

Part of your answer depends on what language you're using. I know that in Python, it's pretty simple to move procedural code into a class, or a more formal object.

One of my heuristics is a based on how the "state" of the situation is. If the procedure pollutes the namespace, or could possibly affect the global state (in a bad, or unpredictable way), then encapsulating that function in an object or class is probably wise.

Symphonia

Answer 17

My two cents...

Advantages of procedural programming

• Simple designing (fast proof of concept, battle with dramatically dynamic requirements)
• Simple inter-project communications
• Natural when temporal order matters
• Less overhead at runtime

The more Procedural code become good the closer it's to Functional. And advantages of FP are well known.

Name

Answer 18

I always begin designing in a top-down fashion and in the top parts it's much easier to think in OOP terms. But when comes the time to code some little specific parts you are much more productive with just procedure programming. OOP is cool in designing and in shaping the project, so that the divide-et-impera paradigm can be applied. But you cannot apply it in every aspect of your code, as it were a religion :)

Fairground

Yes, but too long functions are not nice either. Also a service object that has only a function can later benefit from being an object / class. – Prohibitory

If you have an isolated part of code with a "switch" statement with 3-4 "case"s it's useless to apply polimorphism there. You would create a base class with one pure virtual method, 3-4 concrete classes, each one of the implementing that method and everything just to replace 10-20 lines of code! – Fairground

Answer 19

If you "think OO" when you're programming, then I'm not sure it makes sense to ask "when should I revert to procedural programming?" This is equivalent to asking java programmers what they can't do as well because java requires classes. (Ditto .NET languages).

If you have to make an effort to get past thinking procedurally, then I'd advise asking about how you can overcome that (if you care to); otherwise stay with procedural. If it's that much effort to get into OOP-mode, your OOP code probably won't work very well anyway (until you get further along the learning curve.)

Bannister

OOP is my natural mode. I want to know when I should use a procedural approach. – Lyrism

Answer 20

IMHO, the long term benefits of OOP outweigh the time saved in the short term.

Like AZ said, using OOP in a procedural fashion (which I do quite a bit), is a good way to go (for smaller projects). The bigger the project, the more OOP you should employ.

Cammi

I don't think there's such thing as "using OOP in a procedural fashion" but I get what you're saying. It sounds to me like you mean something like "using procedural code with objects." There is a different between using objects and object oriented programming. :-) – Endospore

Answer 21

You can write bad software in both concepts. Still, complex software are much easier to write, understand and maintain in OO languages than in procedural. I wrote highly complex ERP applications in procedural language (Oracle PL/SQL) and then switched to OOP (C#). It was and still is a breath of fresh air.

Characharabanc

Answer 22

To this point, the arguments of using OO for DRY and encapsulation is just adding unnecessary complexity in terms of how implicit it is and just sheer of how many layers that a class can inherit a lot of properties and methods into it.

not to mention that it's really hard to design a good OO cause you'd end up adding unrelated/unnecessary things that are going to be inherited throughout the whole layers of classes that inherits them. which is really bad if one parent class gets messy, the whole codebase is messy. and gets refactored.

also the fact that those inherited properties are not specifically fit into the use case to the class that inherits it which requires to be overridden. and to the ones that don't need them at all just have them for no good reason.

for something that does not need to be shared, sure there's abstract properties. but you'd end up having to implement them in all the instances that tries to inherits them.

this inheritance is just too magicky and gets dangerous.

but I'd give OO credit on how it's good at enforcing of what should be available. but then again it's too much power that is really easy to be wrongly used.

In my opinion, final class should be the default. and you need to deliberately choose if you want to allow it to inheritance.

Accipitrine

Answer 23

Most studies have found that OO code is more concise than procedural code. If you look at projects that re-wrote existing C code in C++ (not something I necessarily advise, BTW) , you normally see reductions in code size of between 50 and 75 percent.

So the answer is - always use OO!

Gwenore

This confused the hell out of senior management where I used to work. They insisted on using lines of code as a productivity metric and couldn't understand why we seemed to be going backwards. – Lunna

Really? 75%? Could you post a link? If that's true then just imagine what reductions they could have achieved with a very-high-level language like Lisp, Haskell or Ruby – Alarmist

OO increasing complexity by around 300%, it is not reducing complexity – Rader