Those terms are language independent. They mean the same whether they are applied to Perl or any other programming language capable of those style of use.
See Procedural programming, and Object oriented Programming for better explanations than anyone is likely to produce here.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
I agree with BrowserUK. However, if you need a slogan, I'll give you one.
Procedural Programming is based on putting together subs that work on data as parameters. The smarts is in the procedures, that may behave differently depending on what kind of data you pass them. Object Oriented Programming is based on linking together smart data, the objects, that know how to manipulate their own data themselves. So the smarts is in the objects.
You can do the same, programmingwise, in both. However, the organization of the code is inside out for one compared to the other.
For example, if you were to implement addition in procedural programming, you'd put the code for adding integers, floats, complex numbers, matrices... all together. And the codes for subtration would be put somewhere else, and yet another place for multiplication...
In object-oriented programming, you'd place all operators/routines for integers together, and all operators for floating point in another place, for matrices yet somewhere else... Inside out. | [reply] |
Procedural code uses stuff like loops and subroutines to manipulate data that is stored in either global data structures or is passed around as parameters.
Object oriented code ties the data up into a bundle called an "object" and associates "methods" with the object. The idea is that you can create objects where the details of how the data can be manipulated is embodied in the object rather than being a bunch separate subroutines and data that get munged together in some fairly haphazard fashion.
The big gain with object oriented programming comes when define the objects in terms of classes and allow the same data manipulation to be applied to different but related data.
An example might be a class that wraps up some database functionality for dealing with tables. So you might have a Table class that allows you to provide the name and structure of the table (the data) and allows you to do things like create the table (given a database handle - most often an object actually) and then do stuff with it like insert new records into the table, fetch records, update records and soon. The nice part is that once you have written the method to do each trick it really doesn't matter what the details of the table are, the methods work for all tables.
DWIM is Perl's answer to Gödel
| [reply] |
Update: corrected typo noted below. Thanks RobPayne
Loops occur in both those programming styles, as well as functional programming where they may be disguised as recursion, and monolithic coding and assembler programming as gotos. They do not form a distinguishing point at all.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
I agree with the point BrowserUk is attempting to make, but the last sentence should be "They do *not* form a distinguishing point at all." It was a small typo, but it makes all of the difference.
| [reply] |