A Programmer’s Discussion: Procedural vs. OO

So I have been writing code of one sort or another for over 15 years (mostly Perl) and there is still one thing I don’t get ... what is the advantage of object oriented programming (OOP) over procedural programming (PP)?

I want to have an open discussion on the topic. Obviously I deal with both OOP and PP, but I am strongly in the PP camp. I am wondering “did I miss the boat”? I heard that Perl 6 will have very strong OOP and possibly will be pure OOP only, so if Larry Wall (way smarter then me) thinks it is a good idea, I must have missed something.

Here is my simplified position, I find OOP harder to read, harder to maintain, and harder to use. PP seems so intuitive and straight forward. I find most PP code I can read and understand with very little in the way of comments or documentation, the code is the code you can see what it is doing (it is mostly self documenting). In OOP I find that I am constantly trying to figure out what it is doing, it seems more... nebulous. I normally have to jump around more; it is not like PP where you are mostly reading top down.

Tell me what you think and help me expand my knowledge. I am not trying to promote or bash either method, I am trying to learn, and I hope all of you will respond in the same spirit. When you respond please let us know what camp are you in.

Some possible talking points for the subject:

What can OOP do that PP can’t? or What can PP do that OPP can’t?

What advantages does OOP have over PP? or visa versa?

Performance benefits of OPP/PP?

Maintainability?

Re-usability?

Readability?

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Call me old fashioned

Anonymous's picture

Call me old fashioned but I really like Nicholas Wirth's Modula-2 and was disappointed it never became more popular.

Modula-2's concept of separating the definition modules from the execution modules made it easy to utilize inheritance, etc and extend/reuse libraries.

Threads, messages, etc were all part of the language itself.

And it was a very easy language to learn.

The biggest advance of OOP is

Shawn H Corey's picture

The biggest advance of OOP is that you can black box your code. You can separate what it does (its interface) from how it does it (the internals). This can lead to more comprehensive testing since all you need to know to write a test is the interface. You can write an entire test suite for the objects even before writing any code.

The problem with OOP from a mathematical point of view

Enrique's picture

From a mathematical point of view a software is better when its entropy (the number of possible states at a given instant in time) is lower.

Encapsulating data into objects provides for lower entropy and so for better code (that's actually possible with structs in PP so is actually no advantage for OOP).

*BUT* attaching functions to object provides for higher entropy and so for worse code. A function has the lower entropy when it has no internal state, just takes input data, process it according to an algorithms and output the result. *BUT* OOP favors functions whose behaviour depends on the object instance that behaves like an internal state.

Still some commons and good programming patterns and architectures like event-driven programming, interface and test-driven design are usually better promoted in OOP languages/libraries/frameworks. Actually PP can also make use of event-driven, interfaces and test-driven design but that's not the case in practice.

Another big pitfall of OOP is that of "inheritance". I think it's has been clearly demonstrated over the years that inheritance is a wrong design pattern, just as bad idea as using "GOTOs". Still most OOP languages promote "inheritance" and that's really a big problem.

Inheritance

Doug.Roberts's picture

" I think it's has been clearly demonstrated over the years that inheritance is a wrong design pattern, just as bad idea as using "GOTOs""

I believe you will find that this rather academic-sounding opinion is not universally shared. Inheritance can be abused, but it can also be used effectively to implement effective OO designs. The combination of inheritance and containment has been repeatedly used to implement large, sophisticated ABM simulations by project teams that I've worked with over the past two decades.

A tool placed in the hands of a sloppy or unskilled craftsman will produce poor quality product, now mater how sophisticated the tool is.

--Doug

For non-OOPers

Anonymous's picture

You who don't like OOP, you might want to check out Google's Go programming language. Google for "go language" to find it.

Both have pros and cons

Anonymous's picture

I don't understand why people can't believe these types of things have BOTH pros AND cons. (oh great, now I'm going to get flamed by BOTH sides)

Personally, I like to use OOP when creating an app I know is going to get big. Anyone who says it's hard to find stuff in an OOP-written app is looking at an app that was not written well (or are not familiar with the design patterns being used). After learning a few basic design patterns and the light comes on, things may make better sense to many of you. Many people I've met who don't like OOP are either lazy or don't want to learn anything new...usually both. (uh oh, now I've done it)

If I'm writing something that needs to perform very fast or run through lots of iterations, I'll go at least partially on the PP route. Of course, on the same note, anyone who has had to deal with searching for a bug in 50000 lines of code in a single file may start to not like PP.

BOTH OOP and PP can be done badly. This is the fault of the developer, not the code.

Is the climb to OOP worth the view?

Ed Young's picture

I've been programming professionally for the last 38 years. I grew up on FORTRANs, BASICs, Pascal, C, PL/1, assembly languages, and more recently Perl, Java, C++, and Python. I was a very strong PP programmer. When OOP came along I decided to really learn it, to think in it so to speak. It took me about a decade to wrap my head around OOP, unlearning a lot of PP thinking along the way.

The view was worth the climb.

I still use PP for small utilities, and quick, throw away solutions. But I reach for OOP when the program gets large. I can simply handle more complexity easier with OOP.

I think of PP programs as function trees emanating from the root function (e.g. main() in C). There is some cross-linking in the branches (for repeatedly used functions). Reuse is at the function level.

I think of OOP programs as instances of objects with self contained data and behavior working together. Reuse is at the object level where behavior and data can be inherited, then enhanced or modified. Like objects can be called on to do the same thing if the base objects they inherit from are the same.

One of the nice things about writing in objects is that you don't have to explicitly call initiators and destroyers. Once they are programmed into an object they are called automatically when the object comes into and goes out of scope (an early example is setting and resetting jump vectors for RS232 communications, it would have been nice to have objects then).

Error handling in the object oriented languages also seems to be much easier. The try/except/finally constructs allow you to easily bail out deep in a program with a reasonably managed recovery.

I use duck-typing languages whenever I can. They are so much simpler to write, comprehend, and maintain. I use pychecker to eliminate most of the run-time errors when using Python. That said I would probably not use a duck-typing language to write autopilot code for an airplane.

If you want performance, go

Anonymous's picture

If you want performance, go procedural. If you want to model a complex environment go OO.

Procedural programming enables you to optimize the interaction between the components to get he maximum performance, albeit at the expense of simplicity and ease of maintenance.

OO enables you hide hide the details. The price you pay is the overhead to invoke all those methods.

In the end it comes down to what you are trying to build. I can see the benefits of OO but after thirty some years of writing (z/OS) assembler, I know which camp I am firmly in and I am not about to change my spots now!

Well, Edsger Dijkstra said it

Hans Bezemer's picture

Well, Edsger Dijkstra said it all: "OOP is an exceptionally bad idea that could only have been invented in California". That's why Alan Kay still doesn't like the man. Personally, I mix both. When you want to abstract a datatype and forget about all the dirty things involved, you choose OOP. When things get fuzzier (e.g. when writing a preprocessor), you're usually better off with PP. OOP is like working in a big organization: when you want something straight, you're never faster. When you want something special, it gets you into a hell of red tape. Of course, there are some basic flaws in the design of OOP, especially when objects interact (preferably of the same type) and the mangling of the symboltable is just a dirty kludge. Red flag is when you need an object browser.

Some more comments on OOP

Rustom Mody's picture

1 Dijkstra

Object-oriented programming is an exceptionally bad idea which could
only have originated in California.
Well this Dijkstra quote is unsourced according to
wikiquote

2 Linus Torvalds

C++ is a horrible language – made more horrible by the fact that a lot
of substandard programmers use it
Linus

3 Stallman

C++ is still discouraged for Gnu Software
Richard M Stallman
rms

4 Knuth

With object oriented programs, we have much less of an understanding
of how we would ever prove that they don't have bugs. This is a huge
gap. If people can understand OOP, they ought to be able to prove
that the programs are correct.
Knuth

5 Paul Graham

Paul Graham
quoting Rees

6 Alan Kay

Actually I made up the term "object-oriented", and I can tell you I
did not have C++ in mind.

  • Sun Microsystems had the right people to make Java into a first-class language, and I believe it was the Sun marketing people who rushed the thing out before it should have gotten out.
  • If the pros at Sun had had a chance to fix Java, the world would be a much more pleasant place. This is not secret knowledge. It's just secret to this pop culture.
  • I fear -as far as I can tell- that most undergraduate degrees in computer science these days are basically Java vocational training. I've heard complaints from even mighty Stanford University with its illustrious faculty that basically the undergraduate computer science program is little more than Java certification.
    • ACM Queue A Conversation with Alan Kay Vol. 2, No. 9 - Dec/Jan 2004-2005

    Alan Kay

7 Bertrand Meyer

The first thing students learning Java see is

public static void main (String [ ] args) throws IOException

There are 6 different concepts there which students are not yet
ready to learn.

And this is just as true for professional developers
Bertrand Meyer

8 Joel Spolsky

Nothing about an all-Java CS degree really weeds out the students
who lack the mental agility to deal with these concepts. As an
employer, I've seen that the 100% Java schools have started churning
out quite a few CS graduates who are simply not smart enough to work
as programmers on anything more sophisticated than Yet Another Java
Accounting Application, although they did manage to squeak through
the newly-dumbed-down coursework. These students would never survive
6.001 at MIT, or CS 323 at Yale, (pointers, recursion, functional
programming) and frankly, that is one reason why, as an employer, a
CS degree from MIT or Yale carries more weight than a CS degree from
Duke, which recently went All-Java, or U. Penn, which replaced
Scheme and ML with Java in trying to teach the class that nearly
killed me and my friends, CSE121.
Joel Spolsky

9 Guy Steele

As for C++ - well, it reminds me of the Soviet-era labor joke: "They
pretend to pay us, and we pretend to work." C++ pretends to provide
an object-oriented data model, C++ programmers pretend to respect
it, and everyone pretends that the code will work. The actual data
model of C++ is exactly that of C, a single two-dimensional array of
bits, eight by four billion, and all the syntactic sugar of C++
fundamentally cannot mask the gaping holes in its object model left
by the cast operator and unconstrained address arithmetic.

Guy Steele

We were not out to win over the Lisp programmers; we were after the
C++ programmers. We managed to drag a lot of them about halfway to
Lisp. Aren't you happy?
Guy Steele

Not all OOP languages mangle

Gordon J Milne's picture

Not all OOP languages mangle names. C++ is the major culprit here.

As a C++ user I often feel there is a big (passive aggressive) war going on between the C++ compiler people and the C compiler people. The C compiler people defined the compiler infrastructure that the C++ people live in and so name mangling is the way of the day.

There could have been more co-operation but ... there wasn't.

As a daily C++ once more I find the language awful. Its a real grab bag of ideas from elsewhere all wrapped up in a big ball of mud.

But OOP is a good idea for handling complexity.

Linux works because all the tools are small. X is awful because it isn't.

A car is built on an assembly

Anonymous's picture

A car is built on an assembly line (like OO, usually large programs are developed by a team). Each station of the assembly line adds a component to the car. Their component specializes in doing one thing and cares not about the rest of the car other than that it is receiving the input it needs to function. Take for example the radio. It needs electrical power for input, and it provides sound for output. The radio will work in a boat or airplane just as it would in a car. The car, boat, or airplane doesn't care how the radio does what it does. It just supplies current and expects sound to be output to the speakers.

However, if the car was built from scratch by one individual, that would typically be PP. In this scenario, the radio can only work with a certain car. The radio is hardwired directly into the car, and the car itself is very involved in how the radio does what it does.

Now, say after the car is built, you want to change out the radio. If it was built using PP, you'd have to build the entire car again, with a different radio. With OO, you just swap out the radio without affecting the rest of the car. Similarly, if you were tasked with adding a radio to a boat, you would have to build another boat if you were using PP. With OO, you just "plug in" a radio.

Wow. You do realize PP

Anonymous's picture

Wow. You do realize PP doesn't mean one super huge function, don't you? You can declare functions in Perl. If you appropriately break up the work into functions, then replacing one function is just as easy in PP as replacing an object in OOP. And if the program is designed well, you can have different programmers coding and testing different functions which will eventually get put together in one program. Just because you're using OOP, it doesn't mean you don't have functions which are essentially small pieces of PP code.

I agree with everyone (with limitations)

Jose Tafla's picture

Professional programmer and developer for 25 years, but a hobbyist since 1979. I've done assembly (8080, 8085, Z80, 8X300, 8X305, 6502, 6510, NSC800, 8088, V20, 68000), declarative (Fortran, Basic), procedural (pascal, C), modular (Modula-2), object oriented (C++, Java, SmallTalk), and some that I can't properly (or am too lazy to) classify (VB, VC++, C#, JavaScript, Forth, Logo, LISP, PHP, Ruby, Lua, Haskell, Perl, Prolog). I have also used lex and yacc to create specific languages for particular needs.

If my ex-boss is following this thread, he might spot me and strongly disagree with me, but here's my two cents nonetheless.

Whatever you do in PP you can also do in OOP and vice-versa. There is room for both, but it's up to you to know where to use what. For example, but please don't take this as a rule, constantly changing requirements may make more sense for PP, while complex processes and data may be a haven for OOP. What would you do, then, with constantly changing complex processes and data?

My ex-boss would say it's a waste of gray matter but, for me, the path from assembly to declarative to procedural to modular to object orientation has become a natural progression, and that's why I feel most comfortable with OOP. It has allowed me to write complex programs with little effort, where well-designed foundation classes could easily be extended to support greater functionality.

To make my point, some of the cartoons we've seen on the big screen for the past several years have been created using OOP. Each string of hair, with its own format and color, subject to the laws of gravity and inertia, captured from a different angle by a virtual camera, is an object; the hairy character is another object *and* a container, not only containing arrays of hair, but also skin, organs, limbs, etc, which also are themselves objects. How much effort would you need to make this using PP?

Abstraction

dnielsen's picture

I've been programming for 25 years, from assembler on up, including embedded systems, software tools, and applications. In my opinion, OOP is most appropriate when either a) the characteristics of your system are not well defined or are subject to change (abstract and hide the fuzzy details in an object), or b) there will be a lot of different types of operations to be carried out with the same sort of data (code simplification by creating object methods instead of multiple functions).

I'm glad I'm not alone

Brent's picture

I have always found PP much easier to follow and debug, but that always had me at odds with my (much younger) peers. It's nice to see I'm not alone.

What is the difference of an

Leandro's picture

What is the difference of an object and a element of an array? I tried many times to start doing OOP to feel its advantages but after starting I find out that everything I'm trying to do is as simple (or more) and clear with PP and arrays.

I'm with the original article, I'm, by ignorance probably, to find some application to which OOP is really advantageous. I would like very much to see a simple concrete example of an PP code and an OOP code for which the OOP code displayed a clear benefit.

Lots of differences

Doug.Roberts's picture

An object can inherit methods and data from its parents. An object can have private and public method members. An object can inherit methods and then specialize them. An object can implement polymorphism by containing other objects.

None of the above is true for an array element (unless the array element is a software object itself).

PP vs OOP for event-driven programs

Jim Bell's picture

Was taught PP some 25 yrs ago and learned OOP some fifteen yrs ago. The real paradigm shift for me is the event-driven model for programming. I think OOP is more conducive to develop a event-driven application hence it popularity as an architecture especially in a GUI.

With that said I enjoy PP (back in the day it was called "structured programming") like a first love however in a lot of cases the OOP method gets the job done better (we grow beyond our first love). However, continuing the first love analogy we should still be using the "good" practices we learned from doing PP like modularity. Food for thought just remember an OO program still has a main in it (for you vxworks guys out there, you know what I mean).

Sure, you can do an event-driven/OOP app in C. For example, look at GTK, it has objects with events done in C. I just think the "scholarly" types prefer intrinsically the elegance of an OO language over an procedural one for doing it.

Maintainability and re-use are IMHO better served with OOP because it focuses the developer(s)/designer(s) on the interface(s) within a given system. While I agree PP is naturally more readable to me, at first, and that there can be a bizarreness to lots of OO code, the OO language inherently provides functionality that doesn't exist in the procedural language which can make it more "readable" or "less" klutzy to read than a procedural one.

When your code changes a lot

Laxator2's picture

If the problem that you solve with your code stays pretty much unchanged, then PP is perfect. That was the case when I was writing simulations during my academic years.

However, I this is the scenario that I am faced with in industry:
- The boss gives me a problem to solve.
- I solve and implement it. I tell the boss.
- Then the boss starts: "Now let's change everything", and he gives me a different problem. However, he tells me, "Don't start from scratch, use the code you already wrote".

I don't know if he really needs to do that, or he's simply testing my limit(ation)s.
In this second scenario, I cannot live without OOP, and Python to be specific. I have to write the most general code, and then customize it for the specific case that he wants.

It depends on the application

Doug.Roberts's picture
I've been doing OOP for a while -- I spent 20 years at Los Alamos National Laboratory developing large-scale distributed agent based models written in C++ and hosted on Linux clusters. OOP is a natural fit for ABM implementations because you design the software objects to map to the agents in the model. See an earlier Linux Journal article that I wrote on distributed agent based modeling for a detailed discussion of this.

OOP is not necessarily the best fit for other programming applications, like some equation-based models, for example.

I use functions for actions

Anonymous's picture

I use functions for actions usually, and objects for data mostly. Logic in functions (except perhaps for small, trivial context independent logic) and data access mostly with objects. In other words, objects are the "blood" that flows around and between modules. Well that's how I do it. No overloaded methods, and no polymorphism certainly. Inheritance level only of depth 1.

object-oriented programming techniques

Anonymous's picture

There is something very interesting written about this on Linux FAQ:
The topic "Why don't we rewrite the Linux kernel in C++?" says:

[...]What's important about object-oriented programming is the techniques[...]

[...]Should the kernel use object-oriented programming techniques? Actually, it already does.[...]

http://www.kernel.org/pub/linux/docs/lkml/#s15-3

Both are great in certain

Pants's picture

Both are great in certain situations. What's confusing in when someone tries to write something that should be object-oriented procedurally (like any sort of reader/writer), or something that should be procedural in an object-oriented way (like math functions).

I think a lot of OO people overuse objects because their languages don't have namespaces/modules..

I think it's a matter of personal preference

Anonymous's picture

I have been programming for 25+ years. I've developed using PP code my whole life. I (think I) understand the position of the OOP programmers out there who swear by it, however, I find (as the original poster does) it much more difficult to understand OOP code written by others compared to PP code.

If you are developing a new application, it is probably a safe assumption to say that using OO techniques will lead to a shorter development cycle. Undoubtedly there are other advantages, too numerous (or technical) to explain in a comment. However, all application development must take into consideration the maintainability of the code being produced. It is unrealistic to expect that I will develop this code and FOREVER be the person that will maintain it, therefore the advantages of my using OO techniques is reduced (if not nullified) based on what I will be inflicting on future developers tasked with maintaining said code.

Additionally, the word "nebulous" used by the poster doesn't begin to describe some OO code I have encountered. I have encountered code where setting a property of an object "automagically" causes certain things to happen. If I were the designer of said object, that would be perfectly acceptable, but in the role of a developer tasked with maintaining someone elses code, it is a nightmare.

Just my two cents...

I can appreciate both

Brian N.'s picture

I can appreciate both methodologies. However, I think that most people (especially those entrenched in the procedural process) are confused by the fact that many object-oriented languages still employ procedural concepts. For instance, Java takes much from the C lexicon and syntax (as does C++ obviously). As a result, a certain amount of mojo (which often does not make apparent sense) must be applied so that objects act as they should when they meet the inconsistencies presented by the use of a different methodology concurrently. Ruby, on the other hand, strives to be purely object-oriented (no more data types as such, syntactically free...).

OOP

Anonymous's picture

15 years+ programming experience in many languages.

To answer your points:
> What can OOP do that PP can’t? or What can PP do that OPP can’t?
Nothing

What advantages does OOP have over PP? or visa versa?
> For me the main advantage of OOP comes when applications get large. When you start to have functions numbering more than 50 I struggle to keep them straight. OOP makes it logical to organize things, and it has enabled me to create much more complicated applications than I would have been able to with plain PP. Not that it would have been impossible with PP (previous question), just a lot easier with OOP. OOP becomes a way of thinking. These days I use it even for very short programs that could arguably have been done simpler with PP. Very short programs tend to grow though, and this is where OOP shines.

> Performance benefits of OPP/PP?
There shouldn't be any, but it could depend on your compiler.

> Maintainability?
This depends on how the application was designed/coded. Good code should be maintainable regardless of the paradigm.

> Re-usability?
Same as maintainability

> Readability?
Same as previous 2

QFT

mangobrain's picture

Replying for emphasis - I agree with essentially everything I read in the above post. I should point out that I am in the OOP camp, specifically C++, however I do think that there are a lot of "features" in some OOP languages that can really mess things up when misused. Some of these are missing in C++, some of them sadly not.

For example, let's examine the case of "setting a property" having some "automagic", undocumented side-effects. C++ doesn't have properties with getters/setters that can be overridden - not as a core language feature. It has members (data), and methods (code): if one wants to simulate a property, one typically creates a private data member, and a pair of getX()/setX() methods which manipulate it. This isn't something C++ either does for you or requires - it is a choice. If the setX() method actually has non-trivial side-effects above and beyond the "setting" of "property" X, it probably shouldn't be called setX -- not a big deal, badly-named functions are a problem in PP too. I find that languages where "properties" are a core feature, such as C#, only tend to exacerbate the problem by making people think it's acceptable practice - why else would there be a dedicated language feature?

Same thing can be said for plain-old members, if the member is itself an instance of a class with an overridden assignment operator, but operator overloading is another one of those language "features" which should only be used with extreme caution.

My biggest pet hate is duck-typed languages which lack any sort of pre-runtime type checking phase. In C++, if I write a function template which expects its parameter type to implement a "frobnicate" method, then try to call it on a type which doesn't implement "frobnicate", the compiler stops me dead. In Python (for example), if I write a function which calls "frobnicate" on one of its arguments, then write code which calls that function on an object which doesn't have a "frobnicate" method, it fails at runtime. At runtime! How the F does anyone ever have any confidence that, for non-trivial programs, there aren't umpteen bazillion untested code-paths at risk of triggering such failures? That, dear readers, is why I distrust duck-typed, interpreted languages for anything other than prototyping and experimentation.

However, OOP != duck-typing.

Agreed

Anonymous's picture

I agree. I once did a huge project in Perl using a OOP model. Writing it was great. Fast and intuitive (even though Perl's OOP is a bit of a duck-taped implementation). Later came a time where major modifications had to be made. After pulling the last hair from my head, I restarted the whole project in C++. Type checking is just too important for large projects.

For instance, PHP has a

Bostjan Skufca's picture

For instance, PHP has a feature called 'interfaces' which you can use to define required methods of an object, and then you can specify a method parameter that needs to be compatible with that interface. Still it gives you error at runtime (there is no compile time, doh:) but at fairly predictable point. Pretty much solves your problem. Whether it is PITA to implement/maintain that's another story...

I don't like OOP, personally.

unsigned_nerd's picture

I don't like OOP, personally. It requires too much effort to write a code that yields the same result as when I use PP. An idea, among many other good ideas, I like which I found from Learning Perl (O'Reilly) is:

"... since the number of bugs in a program is roughly proportional to the length of the source code (rather than being proportional to the program's functionality)"

Yep, the OPP version of

Gordon J Milne's picture

Yep, the OPP version of HelloWorld is awful.

#include <iostream>

int main(int argc, char * arvg[])
{
std::cout << "Hello World" << std::endl;
return 0;
}

vs.

#include <stdio.h>

int main(int argc, char *argv[])
{
printf("Hello World\n");
return 0;
}

Except that Hello World isn't an interesting program. All it teaches us is how to create a minimally correct program that can be compiled and run in some environment.

Things get interesting when complexity or multiplicity grows.

Then, depending on your problem, OOP may make things easier than PP.

Its a "toolbox". You need to select the best tool for the job at hand.

I am sorry too

Anonymous's picture

But if you want to write Hello World to file instead of the console see how it goes:

#include
#include
using namespace std;

int main()
{
ofstream file;
file.open("filename");
file << "Hello World.\n";
file.close();
return 0;
}

#include
int main()
{
FILE *file;
file = fopen("filename", "wt");
fprintf (file, "Hello World.\n");
fclose(file);
return 0;
}

even the lines that writes to file which may be used repeatedly in a C++ program is cleaner.

Using file.open(), redirecting to file using << and using file.close() is more readable than using fopen(), fprintf() and fclose().

What can be f? for this example ok, it is file but think of having pattack() or eroar() (well i should be fair, let's say player_attack() or enemy_roar()). you can implement to have player.attack() or enemy.roar() and use alternative attacking for roaring function using inherintence or better using delegation in state design pattern based on the object state.

I'm sorry

Anonymous's picture

But how is there any OOP in this example. You used C++ vs C. Not OOP vs PP.

It all depends

Jason's picture

As to which is better, PP or OO, it depends upon the situation. Some applications lend themselves better to OO than to PP and visa-versa. For example if you were making a chess game, then it would be a good idea to use OO. Each piece is an instance of a class for pieces, there are sub-classes for each different piece type that all have the same functions but different code in them. This allows each piece to be able to know if it can move like you are trying to move it.

I find that OO is useful when you can usefully distinguish things into actual objects. I find PP works best when distinguishing things as objects isn't easily possible, or doesn't make sense.

Source: Recent Computer Science graduate, thus I had both OO and PP beat into mean

COBOL...

nate olsen's picture

As a 30 yr old COBOL programmer (yes, we exist) I enjoy the simplicity of PP. However, I think the difference is paradigmatic (duh) in that the biggest difference is tying "actions" to "actors" & "actees". Which for certain designs makes sense. Not for the batch oriented stuff I typically work on though. That having been said, there is a dearth of unit-testing/regression-testing frameworks for PP in general, isn't there? Or is it just my mainframe bias?

I prefer the OO

Vladimir Zurita's picture

Personally I prefer the OO programming, mainly because of the ease of abstracting the real problem that the program must be solved, it is easier to recreate a real situation with objects.

That is exactly my point of

Bostjan Skufca's picture

That is exactly my point of view. However I have two things that decide whether I will use OO or PP.

1. Length of a program: if program tends to be shorter than, say 300 lines of code, then I go PP, it's completed faster that way.
2. If program starts reaching those 300 lines and there are some segments that COULD be used elsewhere, I convert it to OO with no second thoughts (at least reusable parts of it).

There are another two points of view that one should consider:

a) With OO, the language/paradigm itself helps me focus on the problem at hand, I don't need the big picture to be constantly on my mind. I find it more intuitive to use. For instance, the separation of what is going on within an object and what is done with the object:
- code that manipulates internal object state is contained within given class,
- code that does something with that object is somewhere else
I understand that there are edge cases which blur the lines of separation, and those cases do not occur infrequently.

b) Readability: this is the part where it gets tricky. I find OO generaly more understandable, however this only applies if there is not too much weird inheritance involved (bad code design decisions in early stage of development). In any case, one benefits greatly from using IDE which has object/class explorer which resolves all inheritance and displays all object/class methods and properties, defined and inherited. Reading code of classes with 5th level of inheritance from plain source files with only simple ASCII editor is PITA.

Me too....

Anonymous's picture

20+ Years of Programming. I saw the OOP stuff coming in Turbo Pascal and got all excited. Then I was confused, mystified and un-impressed. I thought it must be a fad. Then I thought the Internet was a fad too.

I used to think there were 10 types of people; those who under stood computers and those who didn't. My current theory is that they're are lot's of types within those who do. Otherwise there wouldn't be so damn many languages!

I like PP for the same reasons mentioned in TFA. I don't like OOP cuz I can't see what's going on. Some people are OK with that. Some people use Windows Explorer to copy files. I'd rather use cmd line.

So, did we miss the boat on OOP? Maybe. Is the PP Yacht going to the same port? Usually. We just see different sights along the way. The bottom line is can you develop code quickly? (Code that works is for SP2) But that's another blog...

OOPs, I didn't mean to PP

War-N's picture

I, too, came very late to OO programming. I am a PHP developer, professionally (yes, get your PHP insults out now) ;) For 90% of what I do, the procedural route (that I'm more used to) does me just fine. When creating much larger applications, though, I have found the partitioning and modularization of the object oriented approach helps me keep everything straight in my mind. Every "action" is nestled away with it's appropriate object. I also think it can be helpful when handing off an application for someone else to maintain.

All that said, I do find it more laborious to use object oriented techniques though.

As always, it depends

Roberto Mercado's picture

Well, i have been a programmer for almost eleven years now. I have seen a lot of programming paradigms. I think each programming style has its own place.
As for OOP, i think its main goal is to make big (and huge) systems easier to design, develop and maintain. This is particularly true for software where there are many people working at the same time. For small-scale development, the overhead of a OO design just isn't worth it.
I'm a theorist and i think that, in order to fully understand the advantages and disadvantages of either approach, you need to study their design theories and principles. In the design theories (opposed to programming techniques) is that you will find these kind of differences.

I completely agree

mlerley's picture

I've been programming for nearly 20 years -- I've never understood the advantages of OO programming. Sure, everything is nicely packaged together and easily reusable, but there are many other ways to do that just as well. Plus, as you say, there is a tremendous amount of jumping around to find/remember what/where various functions are stored/performed. Personally it seems like it adds an oft-unnecessary level of complexity. Huzzah!

Mike has almost 20 years of experience with Linux and PC's in general. He currently runs his own small IT consulting company.

OOP

Paul Kater's picture

I got on the OO wagon quite late as well. I get the idea and such behind it, that you can make methods and functions inside an object which is convenient, but so far I have not encountered any advantage over PP...

I couldn't even program my

Chase Crum's picture

I couldn't even program my VCR...

Chase Crum is the IT Infrastructure Manager for Voicenation and a self-proclaimed Linux FANATIC.

You beat me too it!

David Lane's picture

*FLASH* 12:00 *FLASH*

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

Hey, that's not 1,000 words!

fest3er8's picture

Hey, that's not 1,000 words! Not even close! :)

Electrical tape

bertrapp's picture

Why put up with the flashing when you can put electrical tape over it?

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix