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.

If you have the requirement

JB_SC's picture

If you have the requirement for three data entry forms to be available over the internet you could implement it PP or OOP.

I would choose OOP if:
1.) There was a lot of code that could be shared and reused between the forms.
2.) The data entry forms were anticipated to change often over time.
3.) Many new data entry forms were anticipated to be added to the project over time.

I would choose PP if:
1.) The forms were very unique and few elements were shared.
2.) The forms were static and not expected to change much over time.
3.) None or only a few forms were expected to be added to the project over time.

You could use a blend of procedural and object oriented techniques. For instance you could have three ASPX pages that implement each of the form's views in a procedural way with a page_load and button_submit functions to handle the data entry, but still communicate to an object oriented C# or VB.net Data Access Layer. The procedural forms could also communicate to an object oriented C++ DLL to handle credit card processing on the submit.

To implement it fully with OOP I would have to have an abstract base form class each of the child forms would have to implement. This would complicate things at first, but could save a lot of code rewrite when things change or added in the future.

To implement it fully with PP there would be no form class. Each form would just get its own ASPX page, but would have to implement some of the same code in all three pages. This would complicate things later on if all the forms were required to change (i.e. use SSN# instead of UserID as the primary identifier) or if new forms were added. All the form code on every page would have to be rewritten where necessary.

Surprise: Ancient advocacy alive :)

Gene's picture

Can not help my desire to say a couple of words. My coding experience is 25+ years. And OOP never was attractive to me. Probably, that was due to I always had what OOP could give, thanks to Modula-2 and Oberon-2.

Philosophy aside, coding OOP practice I happened to observe was that OOP provided means mainly for

1) Modularisation (encapsulation).
2) Making reusable code libraries.

IMHO that was the reason of OOP success and that was all what PP could give by means of modules.

Now it is time to recall that (celebarted) OOP method is to create a number of objects and to fire up their interaction by message exchange.

Regarding its methodology, OOP approach seems to be much more obscure than PP. May be, that is due to the fact that it is much more natural for human being to invent an algorithm for a purpose, than to build an abstract machine which would work according to some model in a way that it would implement an algorithm for a purpose...

AFAIC the only domain of OOP methaphor to fit more or less nicely is windowed GUI (interactive graphics) and modelling of automation systems blocks.

Regards,
Gene

modularity vs. OOP

vova's picture

OOP is an abstraction made up of too many false hopes,
thus counterproductive as 99% people see it now ;)
Here we are, real life example:
every comment in this thread [from OO point of view] is derived class
of 26 ASCII letters, but, how useful such abstraction is for the matter?
Larry Well had classic example somewhere: radio tower and plumbing pipe
are made from single base class, but they have almost nothing in common.

Classes hierarchy,...
Vertical inheritance paradigm clearly becomes insufficient,.. then
horizontal (aka transparent) inheritance comes into play,
making a mess from the ideal initial picture.
(forgive me to ask,.. does java has it?.. perl does, but,..)

Isolation,..
Students are getting wrong idea about it, listening fairy OOP tales.
They start to believe that object's properties becomes invisible when
someone's eyes get closed.

Instead learning about modularity, decomposition, protocols, state machines,
a code re-use,.. every and any OO writer most of life reinvents the weel
cloning a classes and methods from zillion similar ones.
Result is: almost every OOP product is looking as collection of procedures,
thus being near imposible for lock-free threading.

I vote for data-driven modular design, -- back to the nature,
to stop lie to ourselve.
OOP as scientific abstraction is fine...
and limited.

Wow.

Doug.Roberts's picture

As long as we're at it, why don't we all go back to driving Model A Fords again, too.

It is possible to abuse OOP best practices, just as it is possible to abuse procedural programming technique. If you don't like the OOP style, don't use it! Enjoy your data-driven approach, just don't ask the rest of us to join you.

--Doug

Model T

Rustom Mody's picture

Are Erlang
Go
Clojure
Scala

model Ts in the programming world?

Model-T Metaphor Misfire

wpeckham's picture

1. Model-T is obsolete and unsafe on modern highways. The first computer languages and concepts ever written are still often the best tool for addressing the kind of projects that they were created to address.

2. I know a man who owns a fully restored Model-T, and makes a nice side-income taking it to car shows each summer. I assume your point is not that we should (or should not) make side income from showing the shine on some older computer languages?

I agree about misuse. Someone once challenged me to write a program in Pascal that they could not desk-check and tell me what it did. HE was not aware that you can ignore the conventions of Pascal and write 18K of obscure code in a single line and it would compile and run correctly. Our best practices in any language or schema amounts to standards we agree make the code more useful and/or maintainable. Ignoring them is somewhat more than just anti-social.

Living in the past

Doug.Roberts's picture

Hi wpeckham,

My point re: Model A Fords was that we could all choose to live in the past if we wanted to. Doing things in the old, comfortable ways that we are used might be, well, comforting.

But not efficient. Modern software languages and methodologies have come a long way since the old data modeling days. Sure, you can still get a job writing COBOL, if money and maintaining legacy code were your only objectives. But todays' computational challenges are much larger than data modeling approaches can manage.

Today's HPC environments utilize hardware configurations of tens of thousands of individual processors, shared memory, distributed memory, temporary and permanent storage. We require more sophisticated software methodologies than the old data modeling approaches if we wish to build and maintain applications that can take full advantage of modern computing hardware.

And, truthfully, not everyone is capable of grasping OO methodologies and using OO-capable languages to effectively implement OO solutions. Any software methodology and language can be abused. The more power a language provides, the greater the potential for unskilled practitioners to misuse it. This was true in the early 1980's when OO methodologies were emerging, and it is probably even more true today.

--Doug

Some might not be able to

Gordon J Milne's picture

Some might not be able to grasp OO but this is a small number compared to the number of people who just cannot understand pointers. For a great many people pointers remain magical.

Joel has a great article (http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html) on this.

The division between OO and procedural is but a hair's breadth compared to that between those who understand pointers and those that do not.

Rather sad

Doug.Roberts's picture

That would be rather sad, if it were proven to be true. Pointers are really at the heart of C and C++.

My own experiences lead me to observe that a great many of supposed software development professionals whom I encounter do not understand even the basics of OO design, much less OO best practices. This is clearly a reflection of (in the United States, anyhow) the poor quality of computer science education.

Which, sadly, does not surprise me.

--Doug

OO religion

vova's picture

Did I ask anyone about changing confession? Not at all.
Just provided a facts those usually are masked by OO mass media noise,
therefore are not obvious.

As most of people say here, what env is personally comfortable, that works best.

Some of us prefer anti-machine (data stream rather then code stream) model,
where OOP [as it main-streamed now] does not make sense a bit.
Thanks God and Larry, perl won't stop evolution by OO-restricting.

i'm, as many others who wrote

Anonymous's picture

i'm, as many others who wrote in here, a long time in software development.

i can fully understand the original intend to open up the discussion.
the main problem of oop is, that you sometimes need to be a
psychologist to understand oop designs of other people well.

oop design depends a lot of a cultural background and common sense between those who are involved in the development process. for me it is hard to find a way in a very large project based on oop because the logic of the group processes behind the scene is not obvious and not part of my culture, so to say.

on the other hand, if you have a look at smalltalk - or squeak -, you have the right tools on hand to get a fast lane to the underlying concepts of the oo design patterns. may it be the class categorization or the method categorization, such a class browser is something which is needed in a good oop environment and it still is totally uncommon.

again, because of the different ways people associate solutions to problems needs you to be "psychologist" rather than a programmer in the oop landscape.

happy discussions

When there are many levels of

Sanand's picture

When there are many levels of "consists of" (or "contained in") relations between your conceptual objects, OOP is a natural choice.
eg: Data Access Objects and Business Objects in SOA

When the data structures you have to deal with are simple, stick to PP (especially when there are complex operations involving multiple data structures)
eg: Linux Kernel

that ain't OO

BuggyFunBunny's picture

-- Data Access Objects and Business Objects

Not to mention Data Objects and Action Objects. Neither set is OO, just procedural semantics in object (java, etc.) syntax. If you want to read real OO, read Holub.

user space versus kernel space

Anonymous's picture

Languages can define grammar constructs and data structures, but need libraries to run. Some PP just make programming easier while others introduce new concepts. C defines memory layout and need libraries to do dynamic linking. OO ususally include dynamic memory management and threading support, and is implemented upon system call interface, while C is the tool designed for kernel. Some OOP like Java even defines own object file format, and most PP either just interpret scripts or compiles to elf. I use different programming paradigm for different projects.

My reason of using OOP

Isaac's picture

I tend to use OOP for larger programs for two reasons. One syntactical, and one pragmatic.

The syntactical reason is that it allows me to use a simple syntax to put code that is used to manage a piece of data just around that data. Clearly, you don't have to use OOP to achieve the result. In OOP, you create a class (or package in Perl), and put all methods (or Perl sub's) needing the class there. Then when you create a variable of that class, you just use the "." or "->" operator to access that method, there is no way you reach the wrong one. In PP, it is slightly more difficult: you create a structure (or, just a Perl sub that returns a hash), and put all methods / subs that need the structure right after the struct / defining sub, all named in a way that use the structure name as the method / sub prefix. Then when you create a variable of that class, you pass the object as an additional argument. The downside is (1) you need to have a consistent style of naming convention, (2) you need to keep recalling what is the type of the variable when writing the code, and (3) you need to keep typing and eventually reading the prefix, even if the variable is clearly of a particular type. A side benefit is that I can now say something like $shape->get_bounding_box()->get_volume(), instead of box_volume(shape_bounding_box($shape)), which I consider as more natural, but the benefit is slight.

The pragmatic reason is that I can use inheritance naturally. People who don't "get" OOP have a difficult time to understand why one will need inheritance. If you have a program filled with switch-case on type code, and from time to time you have to add a new type code, then you understand that you end up having to search the program for all the switch case, which is a hard task. When you have inheritance the type code switching logic disappears, in a way that usually allows you to express the reasons around the groups of switching very naturally. In order to do inheritance in OOP, you just define a subclass in the way supported by the language, be it some "extends SuperClass" or "use base qw(SuperClass)" or whatever. After that, just define the method and you're done. Calling it is also very simple, you just say "$shape->getBoundingBox()". In PP, doing that is at best very clumsy. You end up putting a group of function pointers, or even a pointer to structure of function pointers, into the object, and ensure that the function pointer is put right at all functions constructing the object. Then, to call it, you end up doing something like "$cylinder->{boundingBoxFn}->()" in the best case, "$cylinder->{CylFns}->{ShapeFns}->{boundingBoxFn}->()" in the horror case. In short, you won't want to do that unless you absolutely have to use OO design (X Windowing system comes to mind). Which is a pity, since OO design would make the program a whole lot cleaner.

About your first point - why

Alan B's picture

About your first point - why do you ignore the possibility of a PP "get_volume" and "get_bounding_box" that are capable of discerning the object type? I use languages where it is completely straightforward; I don't know about perl. If you can do that, the syntactic difference between PP and OOP is simply whether you're using () or ->; the functions/methods/subs behave in the exact same way. At that point, it becomes 100% a matter of taste, and I simply prefer the () notation, though the difference is very slight.

You have exactly described

Anonymous's picture

You have exactly described why the C++ syntax is difficult to use. Smalltalk would use:

bbox := self boundingBox.

Which I think is clear...

Tcl might use set varname [someobjectname -getopt boundingbox] (Or it might not... which makes sense if you use the language.)

In Ada05, you get bbox := variable_name.BoundingBox; or BoundingBox(variable_name); with the former being (mostly) syntactic sugar for the latter (which is the only way you would have called it in Ada95.)

All of those make more sense (at least to me) than the C++/Perl lingo. C++ is a really poor language, IMHO, and far too often the whole notion of OO code is unfairly painted with the same brush of confusion and distaste.

(And please don't flame me for minor syntax/style errors. The only one of these I use regularly is Tcl.)

One of the things that struck

Anonymous's picture

One of the things that struck me in the original article was the comments on 'readability' of code. Now, I find C++ as a language to be an ugly hack, with Perl only slightly better. Regardless of this aesthetic opinion, lots of people seem to get work done in them and lots of really good work for that matter. So that's the background on me..

I find most C++ code out there to be completely illegible with Java only a bit better. Python and Ada read easily. C is difficult to read, Perl far worse. Tcl seems natural and I don't have an issue with POSIX shell stuff or Objective-C. This is again personal.

Mostly, I code in Tcl as it suits the scale of most of my projects rather well and supports (simultaneoously) several different programming models. Sometimes, I write using OO techniques and build finished object interfaces when I am putting together something with broad application where I want to not care about the implimentation details when I go back to use it. Sometimes I write ADT-type procedural code where the implimentation is more exposed and that suits what I want. Other times I'm doing transformations on a data stream and want script-style code.

If you are finding that Perl is a good fit for your programming tasks, you probably will find that the work to learn OO methods not worth your time. At the point where you are reaching the limits of the amount of abstraction Perl provides, then you'll discover the places OO becomes useful. As the Ada folks will tell you, it's all about providing greater levels of abstraction and supporting multi-programmer projects.

All answers below are my

Anonymous's picture

All answers below are my opinion and I answered them thinking my way of using both apporach. so they really can be equal or vice versa for other people.

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

none, they can do everything each other can. Actual discussion is about "How" not "What"

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

If you need to write a program that
needs components that you already programmed, and/or
will have components you may need in the future
does not crically needs performance and/or
any other person will be assisting during the development and/or
will be a relatively big
then in my opinion OOP would be anvantageous. Otherwise you may go with PP.

>Performance benefits of OPP/PP?
Think same genius programmer who loves both methods equally, writes programs which does exactly same job in both method, the performance gain would be at most %5 for PP. But a well coded OPP could be much better in performance than its PP alternatives. The impact of the programmer and his capability of using either approach is more important for performance.
Today's compilers are really great in optimization, and computers are very fast and this mostly compensates performance (if there is any) loss of OOP.

>Maintainability?
Really relates to the code. but for me OOP is easier to maintain. It can be easier to narrow down where the bug is to a class and there you go. There can be long examples this subject, but this is enough for now.

>Re-usability?
I think OOP is more reusable. Pernonally i like to write a class that does a great job, use and put it into my toolbox to be able to use it later.

Think it is like writing a program and putting it into $PATH so you -or someone else- can use that program for a another -or bigger- purpose. Nobody needs to know how the program works, only needs to know what it does.

You have a lot of small and big applications, tools that you use everyday that they don't need to be linked each other in any way. You just know how to combine them, like using multiple commands on the command line where you can pipe each others outputs and manuplate them.

>Readability?
I think OOP is more readable, because the you do not have to reread classes that someone wrote (or you wrote several years ago). Just know -or remember- how to use the class.

VERDICT:

Use the method you like and feel comfortable. But, people afraid of changes, give it other method a try. But do not give up easily, learning curve may be steep but be patient and learn the other method enough that it shows you what capabilities it has. Now You can decide which method you like and feel comfortable and go on with it. Like giving enough try to use emacs or vi and selecting one over another, not blindly sticking to one.

All answers below are my

Anonymous's picture

All answers below are my opinion and I answered them thinking my way of using both apporach. so they really can be equal or vice versa for other people.

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

none, they can do everything each other can. Actual discussion is about "How" not "What"

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

If you need to write a program that
-needs components that you already programmed, and/or
-will have components you may need in the future
-does not crically needs performance and/or
-any other person will be assisting during the development and/or
-will be a relatively big
then in my opinion OOP would be anvantageous. Otherwise you may go with PP.

>Performance benefits of OPP/PP?
Think same genius programmer who loves both methods equally, writes programs which does exactly same job in both method, the performance gain would be at most %5 for PP. But a well coded OPP could be much better in performance than its PP alternatives. The impact of the programmer and his capability of using either approach is more important for performance.
Today's compilers are really great in optimization, and computers are very fast and this mostly compensates performance (if there is any) loss of OOP.

>Maintainability?
Really relates to the code. but for me OOP is easier to maintain. It can be easier to narrow down where the bug is to a class and there you go. There can be long examples this subject, but this is enough for now.

>Re-usability?
I think OOP is more reusable. Pernonally i like to write a class that does a great job, use and put it into my toolbox to be able to use it later.

Think it is like writing a program and putting it into $PATH so you -or someone else- can use that program for a another -or bigger- purpose. Nobody needs to know how the program works, only needs to know what it does.

You have a lot of small and big applications, tools that you use everyday that they don't need to be linked each other in any way. You just know how to combine them, like using multiple commands on the command line where you can pipe each others outputs and manuplate them.

>Readability?
I think OOP is more readable, because the you do not have to reread classes that someone wrote (or you wrote several years ago). Just know -or remember- how to use the class.

VERDICT:

Use the method you like and feel comfortable. But, people afraid of changes, give it other method a try. But do not give up easily, learning curve may be steep but be patient and learn the other method enough that it shows you what capabilities it has. Now You can decide which method you like and feel comfortable and go on with it. Like giving enough try to use emacs or vi and selecting one over another, not blindly sticking to one.

OOP vs PP

William Peckham's picture

The difference is entirely in your head.
No really!
Code is code, and anything can be done in assembler that can be done in any higher language.
This should be self evident, because every program written in a higher language either gets translated to machine code (just as assembler, only nastier and less efficient) or to a P code that can then be interpreted by some run-time engine that runs machine code.
If you want the greatest performance: you write in assembler. If you want the highest maintainability, use the highest level language. Forth.
For most real-world problems you want a reasonable compromise. Every procedural language since FORTRAN-II has been a compromise, and every one of them has some advantages.
Thinking procedurally is far more efficient for addressing very linear problems, and lends itself well to more complex problems based upon trigger/input-action-output/result modules.
Object/method thinking is far more efficient when the data and actions are conceptually linked, and the triggers or events are poorly defined initially. It is easier to link exiting objects and methods to events that were not imagined when they were conceived than to re-purpose or rewrite exiting procedures.
Neither is really better, each is simply a tool to approach solutions to problems.
Programs and languages do not approach or solve problems, we do.
These approaches were created by brilliant minds who conceived of a way to look at some classes of problem that made them easier to solve.
For the individual developer: the one that is better is the one that works. All else is trivial.

Its Self Evident

madtom1999's picture

If you don't understand the advantages of OOP then don't use it.
I came into programming via chip design where very complicated objects communicate through simplified interfaces and large portions of the design are black boxes and, while I struggled at first, once I got my head round OOP, I found I'd been doing it for years in C (ever seen ****foo[*i];).
Alas once you do understand it it is all too easy to write very complicated (and incomprehensible to non OOP practitioners) almost personal and unmaintainable code.

Procedural code can be implemented iteratively, OOP 'done well' sometimes needs several levels of hierarchy to be envisioned and implemented in one go to achieve something.
I must confess I've never seen an introduction to OOP for procedural programmers that comes anywhere near demonstrating and explaining the benefits well - possibly because everyone wants soundbites and a concerto doesn't fit into two bars.

"If you don't understand the

NewKidOnTheBlock's picture

"If you don't understand the advantages of OOP then don't use it."

Oooops, slippery slope here. This is a two-way argument:

"If you don't understand the advantages of PP then don't use it."

They are both dogmatic, and don't contribute to the actual discussion.

but the writer already knows

Anonymous's picture

but the writer already knows the usefulness of PP

don't criticize when being quiet gives the same information.... just think how much better a day you would have had if I hadn't taken the time to criticize you!

Uh?

NewKidOnTheBlock's picture

C'mon, let's not get squeamish. I think I made a valid comment, and it is not offensive in the least, and just invites more reflection...

Try writing code thats

Anonymous's picture

Try writing code thats multitreaded (and fairly complicated) that uses (locks) and shares data between multiple threads... Your APIs are much cleaner on bigger projects with OOP conventions. For simple apps, PP is fine. And... The *UNIX world of devel is all about apps that "do one thing; but do that one thing well", so PP makes sense as it supports a well defined execution path. As the shift in CSE goes involves more HCI, it is important for software to be robust and informative. Software that does more than just one task, one easy to read procedure.

If you are writing utilities and whatnot, PP is the way to go. If you are writing for a interactive app, OOP is the way to go. IMHO.

Perl

Dan the Man's picture

A modular procedural language can achieve everything an object-oriented one claims to, or at least the things that are actually useful. But that's not to say there are only two paradigms to chose from or that applicative or logic programming isn't better than PP and OO.

I like SED, of which Perl is a superset, which does not conform to any of the paradigms, but at least it has things resembling variables and GOTO's. Now how would you classify Perl?

Both together

Sammo's picture

I was never into OO, even when learning it at university - I always argued with lecturers that I can solve all the programming exercises with PP and they said "Yes, but...".

I got into OO when building database driven websites initially. Now, I think it is hard to argue PP over OO for this application. There are so many reusable objects for a database driven application - users, customers, pages, products, shopping carts, orders, etc.

You then have PP sub routine based front-end code for the websites which changes on a project by project basis, but you can pretty much reuse all of the data objects in every project and simply not include ones that are not needed.

For what it's worth, I have found it much easier to work with other peoples' OO code than PP in most cases. Perhaps not relevant for most people here, but having also written some .Net classes for some websites, I was able to reuse the same objects for a Windows application.

Ask the right question

NewKidOnTheBlock's picture

What can you do in OOP that you can't in PP?
What can you do in PP that you can't in OOP?
Answer these questions and you'll have answered the OOP vs PP big philosophical question.

I love this in BASIC - seriously:

ON COM1: GOSUB MYROUTINE

OP, PP, assembler, microcode

Bartolomeo Nicolotti's picture

OP, PP, even assembler produce ALL machine code instructions that are executed by processor, but

PP is "portable" on different arch, see linux kernel, while assembler is not
PP is more "powerful" than assembler, I hope nobody has doubt abou this, but if you've to write a driver or boot loader, something has to be written in assembler
OP is more "powerful" than PP, I mean that there're things that can be written faster in OP and have less maintanence time

OP has classes and inheritance, this helps to keep code tidy => good
OP is polimorfic hiding details and reducing code size => good
OP hides variables this reduces the state space of the applicatiom => good

You can do the same with PP, as you can unscrew a screw with a knife, but a screwdriver is better, but if you've to change the engine of a boeing you need the right tools, even if not every body need these tools.

OOP problem

Hans Bezemer's picture

The problem is right there: in OOP a bottle unscrews itself, while in PP you pass the bottle and corkscrew to an unscrewing procedure. I find the latter a better representation of the real world.

Um, depend really

Anonymous's picture

In OOP the dog runs itself, while in PP you pass the dog and the legs to a running procedure. Which is a better real world representation now.

Unfortunately, most things are based on interaction IRL

Hans Bezemer's picture

.. and consequently the things that do fit OOP are not programmable. But to cut this proofless conversation short: http://doc.cat-v.org/programming/bad_properties_of_OO .

Unfortunately, most things are based on interaction IRL

Hans Bezemer's picture

.. and consequently the things that do fit OOP are not programmable. But to cut this proofless conversation short: http://doc.cat-v.org/programming/bad_properties_of_OO .

did it my way in oop

tsolox's picture

the problem with oop is that, it encourages the programmer with so many ways of expression. The effect is that, the resulting code becomes tuned so closely to the brain of a particular programmer which then is very alien to the rest of us. In PP, there is fewer chances of this happening...

Real world or Machine world ?

bug1's picture

I see the job of a programmer as translating real world problems into the realm of the machine (computer).

Some says languages that are closer to human understanding are advantageous, but personally i just seem them as a job half done.

Procedural to me, is closer to how the machine works, so its a more "pure" form of programming.

it depends on the size of the codebase

Bartolomeo Nicolotti's picture

As said by Bjarn Stroustroup in "The C++ Programming language" the OOP is good when the lines of codes you've to manage are many, something like 1 million. If you've a web site with a couple of pages it's one thing, but if you've to build a complex site like cms OOP could help you to keep things tidy, for example avoid global variable, keep access to variable cheked, ....
As every tool it can be used in the worst way.

It's about the data

Anonymous's picture

As somebody already mentioned, a huge point for OOP is that it is data driven, not flowchart driven. If your biggest issue is managing all the procedures, then procedure programming is for you. If you are more concerned about your data, OOP is for you.

At some point, you will have more data than you can handle. In ancient days, dinosaurs and global variables ruled the Earth, and non-tiny programs were hairy. This was often resulted in spaghetti code that was impossible to follow. Later, modular programming came along and made procedures easy to follow, and limited the amount of data you had to deal with at any one time.
Now, we also can choose to go OOP and revert to spaghetti code. But running OOP lets us make simple programs (objects) that manage our data for us.

I saw the light after writing some python code that handled asynchronous network results in Fortran (real programmers can write Fortran in any language). It took [REDACTED AMOUNT OF TIME] until I happened to get how OOP works and rewrite (and debug) the thing in OOP. This is probably an extreme case, but if your data is driving the code (pull packet, put together with other packets based on whats in the packet) OOP is the only choice.

OOP evolves naturally out of experience with PP

Anonymous's picture

Most of my programming experience is in PP, but the more of it I did, the more I found myself re-inventing the concepts of OOP and pretending the language I was using supported it.

For me, defining an object is a very natural approach to solving classes of problems (no pun intended). You define the attributes of the object and use a "class" as a formal way to group together the operations you want to be able to perform on the object. You think about all those operations at the same time, and so can assure yourself that you're being consistent about it, not making different assumptions with respect to different operations.

interfaces

Alex zungwungy's picture

The idea above about data driven being OOP is rubbish. I've written procedural stuff for 25 years that was data flow driven.

What it does do is (comparing C to C++) mean you have tools that automatically handle aspects of the interface for you. So you define an object and you have a common interface, you need a different set of functionality with just an extension to the interface you create a derived class and add to it.

If you are doing it in C you are usually handling pointers to structures and having to basically do type checking on the structure to cast it etc but with C++ that gets looked after for you.

True, my compiler is

Hans Bezemer's picture

True, my compiler is completely data driven AND procedural. Three tables is all it needs. The advantage is I don't have to figure out which procedure goes with what piece of data (don't talk to me about "friend" methods - they violate the basic methodology of isolation by being shared by and depending on two objects) and cram the darn thing if it doesn't fit.

OOP is a way of localising

Benjamin's picture

OOP is a way of localising data (state) and code (procedures).

So, for example, rather than writing several procedures for different data types (ie. collections) or writing a complex procedure to rule them all, you can attach specific procedures to specific data types.

This isn't useful when you have only a few data types or only a few procedures but as the software grows and they start to explode in number you'll need some form of localisation to manage them.

scriptors vs coders

KevinL's picture

I think users of the P languages tend to veer to PP naturally especially if they are self taught or beginners.
thinking linearly to reach an objective is quite straightforward! *pun intended

OO is probably the natural progression that is a leap is taken when the benefits outweigh the cons of verbose documentation of objects, working solely in one language only so that you can have a Grand unified library

I am convinced by OO principles but I find it hard to implement it in the field of bioinformatics when the data format changes quite often and I have to clobber new scripts to work through stuff. if I was writing a software that dealt with limited data types and I am just implementing new functions then I think i might have to OO my code.

What about new concept of programming

New away's picture

Is it possible to program in new method to tackle both PP and OOP? Programming on natural language like speaking,

Love OOP

christian barthel's picture

Hello all together,
i started learning programming a year ago and guess what, we've learned it with oo in java. I must say: "I love it!!!" I read a lot about functional and procedural programming but in oo, you have a clear structure and you can use your code again. Sometimes, it's hard to figure out what a class is doing, but if you know what a class is providing (such as variables and methods) is's great to have all the things about this object in one single file.
I think the abstraction level is in oo higher than in pp and you can write larger programs.

Not either-or... both

steve steve's picture

Perhaps an unusual perspective on the subject, however I'm a long time PP and now "OO" programmer _and_ writing full blown OO code.

Inside of every object is procedural code.

Your objects are like small programs sending messages to each other. Hence Alan Kay's regret that he didn't call this message-orientated.

So you write your code procedurally, wrap it up in objects, and shape your procedural code so that it sends and receives messages.

Ignore inheritance, it's a minor part of the OO concept that receives too much attention because it's the most obvious difference.

OOP is more natural

Innocent Bystander's picture

I have 25 years of programming experience. I started with PP. Played a little bit with OPP. I made the effort of learning OPP design in 2004, when I started with .NET and C#. My classes were clumsy and generally look like a PP module stuffed in a class. Then I read a book about design pattern, it looks too abstract but the idea nevertheless stay somewhere in my head.

I work often on existing code written by people who don't understand well OPP. The code is more "Gesticulated Object" rather than OOP. Generally monolithic classed full of dependencies and strong coupling. Hard to debug, fragile to bugs. I am very annoyed by these sloppy code. As a side effects, and I don't know how to explain that. The OOP concept just clicked and flashed in my head. Starting from that moment, I suddenly grasp the true meaning of OPP, I finally use inheritance and love polymorphism. You can say what you want, PP will never equal the elegance of polymorphism.

I am not a genius in programming, but I know PP and OPP, and in my opinion, OPP is superior. Because it is more natural and the code is easier to maintain.

PP for me

Anonymous's picture

I love PP. For 15 years I have often decided to learn OO and I have never been able to make the transition. It's just too hard to change my spots.

What I hate though is that every new language developed in the past 15 years is OO only. As a result my hobby programming has just ceased. There's no language suitable to the type of coding I like. Amiga demo style assembler for instance.

So sick of being told that the programming practises I learned are the wrong way of programming.

Take me back to the day when it was all about squeezing the best performance out of the machine. Rather than todays upgrading the machine to suit to poor oo code written by someone with no knowledge of the underlying system. So they even teach logic, truth tables and operating system fundamentals anymore?

OOP is very complicated stuff

Mathew P V's picture

Personally I find OOP very tough to understand, may be my thought process is more conducive to the traditional procedural method. I have tried to peek into a perl module to try to implement it in a procedural way, but is overwhelmed by its complexity. Understanding an OOP program requires much more brain power(in terms of memory). It is difficult to find out what properties an object inherits when the inheritance is more than a few levels deep. This logically should make it more difficult to improve OOP code than PP Code. May be the OOP proponents are very perfect and thorough in their coding that it is complete from the moment it starts working and hardly needs any improvement!

I prefer programming the PP way.

Mostly wrong ..

notzed's picture

Pretty much everyone has it wrong here. OO is fine at abstracting details away - but so is basically every language. That's why they exist and cpu's have branch to subtroutine functions in the first place. Also modelling real-world objects produces pretty poor code so it isn't because all dogs and tables have legs either.

OO is really about *both* code and data re-use.

As soon as you write something more than once the tendency is to put it in a function to re-use it. But as soon as you have a new data-type to work with this falls apart. Polymorphic types address this somewhat but usually in a limited way - unless they are implemented using objects. This is something OO can handle provided you design it properly.

It is more important to get OO design right from the beginning, although if you do then even quite major changes can be cheap.

And this is where the abstraction comes in - it also works for code-reuse beyond your own routine library.

*Programming is really about data, not about code!*

OO is a way to link the two in a re-usable way that becomes difficult to do in procedural code. It lets you write bigger programmes with less overall programming effort and less lines of actual code which means it will have fewer bugs and require less maintenance. All other things being equal of course (and generally they're not - most programmers are bad at it).

If you don't like it, you don't have to use it (and I thought this debate is 10-20 years old so I imagine you've already made your choice), but if you chose to the more you used it the more proficient you would become, and suddenly that hard to track deeply virtual method call would make more sense. It's not something you really need in perl anyway - very few are the perl programs above a few hundred lines long. And they're probably not things you want to go near even if you wrote them yourself :-)

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState