/ Posted In: Back-End Development Tags: Tags: Functional Programming, Object Orientated PHP, Up and Running Difficulty: Intermediate
When you’re brand new to development in PHP or JavaScript, you don’t really need or want to think too hard about programming paradigms. You just want to get things to work. And that makes a lot of sense. But eventually as you go along, you start to wonder. What’s this “OOP” thing people seem obsessed with? Am I doing that? Should I be?
Fundamentally, this article is for people in a place like that. Our goal today is to clarify what these three major paradigms in software development are, how they relate to each other, and which you’ll want to use when. Contrary to popular belief, there isn’t a “right” or “wrong” answer ever.
Before we start breaking down all the programming paradigms we’ll cover, it makes sense to be clearer about what we mean by “paradigms”. To cite a definition which is relevant, the American Heritage Dictionary says a paradigm is:
A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them, especially in an intellectual discipline
This is spot on for us. What differentiates these three major programming paradigms that matter for WordPress developers is that they are a set of assumptions and lenses through which one can understand and construct a program which makes a computer do something useful.
Something useful that a computer can do is make web pages, like WordPress does. And internally, WordPress strongly uses two of the three paradigms we’ll talk about to create what it does. (Procedural and object-oriented, so you aren’t left hanging.)
Paradigms matter because they often travel along with a specific culture of writing programs and thinking about them. There is very real tribalism that has object-oriented programmers and functional programmers sneering at each other in some circles and circumstance. Fundamentally, understanding these paradigms well allows you to be more comfortable writing your code.
The Paradigm We Won’t Discuss: Declarative
One interesting paradigm that does matter for WordPress is declarative programming. In declarative programming, your define things that should happen or be, but you don’t write any control flow. That means: you don’t say how but just what. Though the classification of these things gets pretty hazy and people argue about terms, both HTML and CSS are examples of declarative programming.
You create a “program” which is meant to state how the world should be, but nothing about how that world you’ve defined should come into being. Fundamentally, that part is where the programming done by the makers of a web browser takes over.
So declarative programming is important to WordPress, and the web as a whole. But it’s also lack logical control flow you do in languages like PHP and JavaScript. (This not to say that CSS isn’t complicated, I often find it hard.) But the fact that this paradigm is so different is why we’re not going to say more about declarative programming.
What’s Procedural Programming?
One of the most common ways that
functions are used in PHP is in fact as a kind stored procedure that redoes the same mechanistic procedure whenever called. This is not “functional programming,” which we’ll cover last.
The first programming paradigm that a new developer is likely to learn is procedural or imperative programming. If you’re a stickler, those two are different. For me they’re close enough that it doesn’t matter.
Fundamentally procedural or imperative code is something that directly instructs a computer how to complete a task that you want it to do in logical steps. Rather than declaring the world’s state (as we mentioned declarative things like CSS do), you’d define that you shall make this things by cycling through this, appending it to that, and putting the result here.
Much of WordPress is fundamentally procedural, in that (theme template files, for example) are a direct set of very literal PHP and WordPress function calls that together accomplish the creation of a web page. This procedural style has a great advantage that it is less confusing than many alternatives, and there is less routing around through lots of different complicated concepts for most newer developers.
One common (and understandable) thing that confuses people (me included) is that the use of functions doesn’t in any way mean you’re not doing procedural programming. One of the most common ways that functions are used in PHP is in fact as a kind stored procedure that redoes the same mechanistic procedure whenever called. This is not “functional programming,” which we’ll cover last.
NEGATIVE THINGS PEOPLE SAY ABOUT PROCEDURAL PROGRAMMING
The biggest knock against procedural programming is really that it’s among the oldest ways of programming. As a result of this, it’s derided as outmoded and generally not very cool. But those are pretty soft complaints. More concrete complaints that I think are good:
- It is often hard to think clearly about the overriding program. Naming procedures with functions can help to simplify the machine-like nature of procedural code, but fundamentally the way humans and computers think aren’t that similar, so code that hews too close to what machines like confuses humans often.
- There are no abstractions. Good programs abstract simple things from more complex underlying realities. They favor human comprehension over machine efficiency. There are times when you can’t have this for performance reasons, and in those cases procedural code can be faster and thus better.
GOOD THINGS ABOUT PROCEDURAL PROGRAMMING
That said, some really good things come out of procedural programming too. The first and most important is that it’s not over-abstracted, which can be a real help for newcomers. Understanding objects generally seems to feel more complicated to newcomers than a few function calls.
Procedural programs can also be faster than most alternatives. This is especially true historically. You easily get the maximum performance out of procedures because you’re “empathetic” to what the machine’s most efficient way to perform a task is. If you can do it in one call rather than 500, when you write procedural code you generally realize and do this.
What Object-Oriented Programming Is
We as humans are used to thinking about objects.
Fundamentally, the difference between procedural programs and object-oriented ones is that object-oriented (OO) code will have entities. Something like a “message” in a system which can be “made secret”, “marked as read”, “deleted”, “sent”, “drafted”, etc.
In a procedural-paradigm, you’re forced to pass around a message variable between different functions, like create_draft_message($message) or delete_message($id), etc. All of this is workable, but as you work with it longer you start to forget whether a specific procedure needed the message itself vs a numeric ID vs something else. So you’re continually having to research your procedures.
In an object-oriented program, you instead have a $message object, which is usually an instance of the Messageclass. This object has properties that people can be publicly read, like $message->was_read and actions that it performs like message->destroy(). These are helpful, because we as humans are used to thinking about objects. We understand the idea that named things emerge from the chaos of the world and makes it easier for us to understand that world. That’s what a “chair” is, after all.
WHAT’S BAD ABOUT OBJECT-ORIENTED SYSTEMS
The objects are a lie.
The most powerful complaint about OOP is that the objects are a lie. Fundamentally, the machine doesn’t understand or think in terms of objects, so some things that people do with objects which make perfect sense conceptually are terribly poor performers on the machine. This is because, under the hood, an action on the object can make anything from zero to 4000 database queries. But because of the encapsulation (not explaining how it works to the world) of an object, the caller may not know the performance cost and may face a steep penalty for their ignorance.
The other thing about OOP that I sometimes find myself frustrated by is that it’s often done poorly. OOP has been the dominant paradigm in programming for more than 20 years now, and it means that hugely divergent patterns of practice emerge and all belong to the same camp. This isn’t a problem with OOP in concept, but it ends up being difficult in practice that a lot of bad programs are made in an object-oriented paradigm.
WHAT’S GREAT ABOUT OBJECT-ORIENTED SYSTEMS
The best thing about object-oriented programs is that we humans are very used to thinking about objects. We’re so used to it that a good object oriented system just feels comprehensible in a way that even the best procedural code can’t. $message->sendTo($user) is just so much simpler than any procedural alternative.
Because of this, they can be really great to read. This is also helped along by the fact that in a good object-oriented system, components are isolated and encapsulate all their important behavior, and defer their non-essential behavior to collaborators. In practice, I just presented a lot of prerequisites that most OO code doesn’t actually meet. But when it does, it’s really good. In a great OO system, you know that when a message doesn’t send properly you need to start by looking at the Message class. Not the db.php file, but the Message class. That’s powerful. (Though you may eventually find the defect in another layer, it’s true…)
Object-oriented programming is central to some important WordPress APIs, perhaps most importantly WP_Query . If you’d like a thorough introduction to the fundamentals of object-oriented programming, and a walkthrough of how those fundamentals apply in practice to WP_Query, check out our course on the subject:
What Functional Programming Is
this paradigm is named for functions in the mathematical sense
I mentioned in the “Procedural” section above that simply having functions isn’t what makes a program “functional programming.” That’s because this paradigm is named for functions in the mathematical sense. A mathematical function, if you remember from algebra, is simply a statement of truth about the world that is self-contained and can be used and manipulated with other functions. That’s what a program needs to be “functional.”
Very little PHP code is “functional” in this way. But some of it can be. And the most sensible place that you might see it in WordPress is when you’re wanting to filter or list long arrays of posts. To that end, I wrote a longer article on the topic:
Essentially, PHP has some functions like array_map and array_filter where you pass in a function and all the elements of an array are transformed by it. You can also, in WordPress, sometimes pass functions to add_action and add_filter in which case you could kind of think of what you’re doing as a bit like functional programming.
But the big thing that makes WordPress hooks not-really-functional is about state. In most WordPress actions (and to a lesser extent filters) you reach into the world outside of your function to change something—check a database value, add some output to the page, etc—because you’re hooking in specifically to change things. Your function can not be said to be stateless (or having no effects outside of its inputs). As such, you’re not really doing functional programming in the most pure understanding.
WHAT’S BAD ABOUT FUNCTIONAL PROGRAMMING?
All the complex operations that functional programmers do a lot are pretty abstract to me and I can feel overwhelmed.
The big thing that I think makes functional programming bad is that you’re going to quickly come up against your not having a PhD in mathematics or computer science or some logic-heavy discipline. I have a pretty good understanding of functional programming (FP) for a non-functional-programmer. But there are kind-of-important buzzwords I couldn’t begin to understand which people talk about a lot when they talk about functional programming. “Functor”, “monoid”, etc are much harder to wrap your head around than objects.
The other related disadvantage, is that you’re doing a lot of putting functions into functions into functions. And just as I’m not a computer, I’m also no math wiz. So all the complex operations that functional programmers do a lot are pretty abstract to me and I can feel overwhelmed. I know this was true of other paradigms for me, and it’s just a bigger learning curve, but it’s certainly nothing to shrug off quickly.
WHAT’S POSITIVE ABOUT FUNCTIONAL PROGRAMMING?
Pure, mathematical functions are easier to comprehend than ones that do magic.
The great benefit to functional programming is that if you’re disciplined about state you’ll have a much better time. Because changes with the outside world are pushed farther and farther apart, you can, when using the paradigm, spend very little time with a head-scratcher (so common in WordPress) of “how did that possibly get to that state?” Pure, mathematical functions are easier to comprehend than ones that do magic.
That’s the big advantage–being disciplined about state makes state much easier to think about and understand. It has another advantage too: massive parallelization is possible. What that means is that as computers are increasingly getting more cores rather than faster processors, your program can better take advantage of them. Few programs today take advantage of this trait, but it’s a big benefit to the paradigm.
Why These Three Paradigms Matter
My hope is that I’ve driven home three essential points today:
- All three paradigms — functional, OOP, and procedural — are good and useful for a WordPress developer
- All three paradigms have strengths and weaknesses
- All three paradigms can be used when writing PHP and JavaScript for WordPress
There is no perfect programming paradigm. And it’s easy, common, and understandable for new WordPress programmers to feel embarrassed about writing procedural code when everyone seems to be talking objects. But I’ll take a well-constructed procedural plugin over a hastily-assembled one made without consideration for the thinking benefits of good objects. Cargo-culted OOP is worse than good procedural code every time.
Fundamentally, the best way to get better at writing code is to try things. Write a plugin two ways, and find which you like better. Opinions are cheap, and understanding the trade-offs of alternatives is undervalued. I hope I’ve helped you do the latter by providing some of the former. Happy hacking!
— Read on wpshout.com/development-paradigms-procedural-object-oriented-functional/
