OOP vs. Functional

Topic: Why is there such a debate between OOP and functional programming, and why should we care?

There are many programming paradigms and they all have their strengths and weaknesses. There are two major divisions, the Imperative/Declarative division and the OOP/Functional division.

Imperative vs. Declarative

Imperative code is like a detailed recipe of small actions for the computer to do. An imperative programmer might like iterating through a list with a ‘for loop’ and access items by index and do some operations on each one in turn. But the declarative programmer would rather use a corresponding algorithm instead – to do the same, or more likely, to do less work for the same outcome. This easily makes it sound like declarative is superior, but hold on! Every single algorithm, yes all of them, every single one is imperative at its core! However, declarative has more card to play, algorithm experts. When you use an algorithm you get to leverage the hard work of developers who are older and wiser than any of us. The one true path is to learn how to write small imperative algorithms and use them declaratively – like a pro.

Object Oriented vs. Functional

People can be quite opinionated about OOP vs. Functional, but it’s important to remember that functional is best… sorry, I mean – no one language or paradigm is the right tool for all jobs. Generally speaking, all programming scenarios can be modeled within every single paradigm. One might produce cleaner, more elegant code for a particular problem. But ‘cleaner’ and ‘elegant’ are very subjective terms. What exactly are we measuring? The look of the code (how it reads) or the control flow of the app (how it runs)? This is an open question.

The Python Paradigm: The One True Paradigm to Rule Them All

1. Python is the most readable language ever. Do we need a paradigm to make it more readable? Nope.
2. Python is one of the slowest languages on the planet. Do we need a paradigm to make it faster? Nope.

Side Note: You can turbo charge computation in Python with custom Precompiled Extensions that are accessed in Python just like normal modules, but they crunch numbers really fast. This performance tip seems out of place here, but it’s not. If you pick one paradigm (or container) over another for performance in Python, you’re just not doing right. It’s like arguing over a 1% bump when you could be taking 1,000% – a 10x speed bump is not uncommon for computationally heavy work when optimized with an extension. Python is awesome! Don’t worry about performance when writing high-level Python, it’s just not worth it. Your time is too valuable to consider going for a 1% gain at any cost.

Side Side Note: Efficiency is not the same as performance. Performance is a measure of how fast code is computed. Efficiency is a measure of how much work is done. If your code does less work, but gives the same output, it is more efficient. If the same code runs faster on one machine than another, the faster machine has better performance. This difference is subtle, but important. Your algorithm could be mathematically perfect in terms of efficiency (and that can affect performance), but the same can’t be said for the effect that performance has on efficiency – it can always go faster next year, but it’s the same amount of work. For more information – search the net for vectorizing data on GPU, this will serve to blur the line between performance and efficiency even more because it delivers both at many levels.

Paradigms are one of the hardest things to learn in programming because you often feel as though you have to take all the knowledge you have about one paradigm and throw it out the window to learn another. You don’t. You do have to develop new patterns and techniques to be an effective programmer though. For example: Any Functional programmer should know what recursion is and how to use it. Conversely, an OOP programmer should know about instantiation and how to control it. These paradigms and the ideas behind them are NOT incompatible. But they are almost always taught separately because they are easier to learn that way.

Pythonistas shouldn’t choose one solution over another, we should learn all of them – or at least as many as we can. The more techniques you know, the more effective you are at problem solving – in general. Python is both Functional and Object Oriented, but not purely either. Python is both imperative and declarative, but not strictly either.

Don’t get caught up in the flame war! We’re all on the same side!