Stateless Object Oriented Programming vs. Functional Programming?

33
votes

One of the prime reasons for the increasing shift in attention towards functional programming these days is the rise of multithreading/processing and the advantages of FP's focus on side-effect free, stateless computation in making scalability effortless.

Certainly, though, in Object Oriented programming, we could also shift to a stateless paradigm, where all objects never get to mutate state. This can be a convention, or perhaps even implicitly supported by the language. For example, in languages that enforce uniform access between object fields and methods, simply not allowing setter methods would accomplish this.

My question is, then, since OO can utilize statelessness and nothing about objects mandates statefulness, is OOP effectively a superset of FP? Are there any additional advantages / features of FP that makes multithreading more practical than in OOP?

3
oopfunctional-programmingscalabilitystateless
I wish people who voted to close without leaving a reason were charged like 5000 reputation. Absolutely my least favorite group on SO. – Bill K
This sort of OO will be nothing but a very limited subset of FP (assuming that no other FP requirements are met, such as first class functions and closures). What kind of semantics for a message would you expect from such an OOP? Message which does not modify state of the object is a pure function. Classes will become modules then. – SK-logic
Certainly I don't see first class functions and closures as a strictly functional feature at this point (though that's where they started). Many object oriented languages can support closures via blocks or similar mechanisms. Also I'm talking about disabling mutability, but not instantiation. One could follow the same pattern used in functional programming where modified state is simulated by composing on immutable primitives by creating new objects and their composing objects on the fly. – donalbain
@SK-logic the assumption about methods becoming functions is completely wrong--they can still access final data in the classes and still exhibit encapsulation and inheritance. This is actually the best way to program OO. – Bill K
@Bill K, it does not matter what can they read - as long as they can't modify the state they're pure functions. And, proper modules provides a much better encapsulation than the typical OOP anyway - check out SML first class modules, for example. – SK-logic

3 Answers

16
votes

It's a question of degree.

The advantages to using a functional language for functional programming are the carrot and the stick. The carrot is that functional languages have functional syntax and semantics and come with functional libraries. The stick is that functional languages can force you to adhere to certain standards. If you do FP in a non-FP language, you get neither of these. You will necessarily be fighting against a state-friendly standard library and have to police yourself to ensure you don't create state.

The analogy to doing OO in C is a good one. There are times when your constraints are such that C is the right choice, and an OO structure is also the right choice. GTK is a good example of that. It's very hard to write a UI toolkit without OOP. However, this means you're taking on work that would normally be done by a compiler. Some things that are easy in one language become difficult or impossible in a language without syntactic and semantic support. I've never seen a C project that emulated multiple inheritance, for example. It's just too much manual labor.

If you were to adopt a functional style in your OO code for the sake of parallelism, it's quite possible you'd achieve the benefits you're after without a lot of pain. But you'll still be missing out on compile-time guarantees that your code is pure, in-language support for FP and the impressive optimizations that FP compilers are capable of these days. It's a trade-off, so this is a decision that must be made on a case-by-case basis, and it's one only you can make.

As for whether or not OOP is a superset of FP, I don't even think the concept is meaningful. In terms of expressing programs they're both completely capable. You can implement an OO language in an FP language and vice versa. Sometimes one is closer to the problem domain, sometimes the other. Regardless, I think your real question is whether or not one must like FP, and the answer to that is, no; use what you like.

I think you should also consider checking out the Actor model, because it is more appropriately OO and not state-unfriendly (just shared state-unfriendly), while still yielding scalability/parallelism benefits.

1
votes

I had this same understanding at one point and was "Corrected". Not being a functional person I don't get it, but apparently there are some tools in functional languages that adapt themselves better to that style of programming.

I think it's like a C programmer saying that since C methods can be combined into a struct and replaced doesn't that make C a superset of OO? In fact, this is how C++ was initially implemented, but it does not make C an OO language.

-1
votes

FP is more about the way you solve problems, than language you use. So no OOP is not superset of FP. Some constructs in FP (mapReduce, ...) can be implicitly converted to multithreaded application. But nothing prevents you from using them in OOP. It's all about mindset.