Stateless Object Oriented Programming vs. Functional Programming?

Question

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?

Shopper

I wish people who voted to close without leaving a reason were charged like 5000 reputation. Absolutely my least favorite group on SO. – Seigniorage

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. – Colic

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. – Shopper

@Colic 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. – Seigniorage

@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. – Colic

@donalbain, if the language is only allowing immutable data, providing first class functions and closures - it is a functional language, by definition. If something is missing - it is a subset of FP. – Colic

@Colic Since I'm not really a functional guy I googled it. "Importantly a function will always return the same result when called with the same arguments." This is not true (at all) of a method that accesses local (even final) variables--they will return different values depending on how the object was instantiated. Can you show a reference to your definition of a function so we can figure out where our definitions differ? – Seigniorage

@Bill K, that funny "calling a method" thingy is nothing but a syntax sugar - for calling a function with an implicit first argument. It is very easy to simulate on top of a pure functional language. – Colic

@Colic I think that you're back to the point of the question.. everything is just syntactical sugar on top of standard C programming :) At least in Java a function is generally designated as not accessing member variables in any way (so it conforms to the above definition, whenever you call it with specific parameters it returns the same result). Functions can always be made "Static" because of this, but a "static" method isn't a function unless it also avoids accessing static class variables. – Seigniorage

@Bill K, no, it's all about semantics. A member of an immutable class is a pure function, according to the strictest possible mathematical definition. You have to get away from the unclean world of programming terminology - there is a beautiful and shiny world of pure math out there. And there is no difference between F(X,y,z) and X.F(y,z). – Colic

let us continue this discussion in chat – Seigniorage

Answer 1

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.

Luxe

Very good points. Slightly irrelevant, but I actually personally really agree with the statement "It's very hard to write a UI toolkit without OOP", and yet we have JQuery (That's an argument for another day though :) ). I've also heard alot about the Actor Model and I'd love to see more libraries available that implement this. All in all, threads definitely seem too low level in environments where state isn't isolated, so any solution, whether its a stateful paradigm where abstractions exist to make thread safety easy or a stateless paradigm that automatically makes it easy, should be welcome – Shopper

Regarding jQuery, in-and-of-itself it only modifies the DOM, which is already OO. It doesn't bring any new widgets to the table unless you use jQuery UI--which introduces "widget" objects. :) – Luxe

Answer 2

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.

Seigniorage

I think you're right in that perhaps 'superset' is not the right term. In the end what we're talking about is different paradigms. I guess what I'm trying to see is if the OO and FP paradigm aren't really very similar in the end, where OO is really similar to the FP paradigm but with the additional consideration of state. – Shopper

@donalbain, OO can't be "similar" to FP. It is entirely different. There is no such a thing as, say, denotational semantics for the OOP. OOP is not a complete paradigm, it can only be used alongside with some complete semantics. – Colic

This is definitely not a field that I'm familiar with. If I'm not misunderstanding by denotational semantics here we're talking about ways to prove that programs are mathematically correct right? – Shopper

@donalbain, no, it is about the way how programs are executed. OOP is, basically, just a type system, and it does not define anything about the underlying evaluation model. FP, on the other hand, is nothing but an evaluation model, which can be combined with a wide variety of type systems. – Colic

Answer 3

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.

Gastrovascular