read


read
or learn more

FP vs. OO, from the trenches.

Jul 22, 2013

I’ve been programming for quite some time and have explored a variety of programming paradigms along the way. From time to time people will ask1 which is better: functional programming or object-oriented programming. Having done both extensively in my time I can exclaim a resounding: it depends.

Lame.

While I’ll never be a major player in the grand Internet flame war, I will say that I’ve had great success following a simple two-point guideline:2

  • Whenever I write some code to deal with data about people then functional programming seems to work best.

  • Whenever I write some code to simulate people then object-oriented programming seems3 to work best.

YMMV.4

:F


  1. Not necessarily me, but they ask nonetheless — I just eavesdrop. 

  2. And even these guideline are not written in stone. 

  3. Although some recent work has given me some insight into Actor-based programming and I must say that it too seems particularly suited to the task of “people modeling.” 

  4. Further, I’ve found that when building a low-level library providing data and algorithmic abstractions then a mix of the two (OO at the bottom with an FP API) seems to work best for me. However, this scenario happens far less often than the other two listed above. 

18 Comments, Comment or Ping

  1. pron

    Absolutely agree.

    For actor-based programming in Clojure (complete with real lightweight processes, selective receive and a very Erlang-like API) look no further than Pulsar: http://puniverse.github.io/pulsar/

  2. My very similar perspective might put it in terms of : to the extent that I see the solution based on algorithms, FP; to the extent that I see heuristics, I think OO.

  3. yeah

    oop is retarded

    if youre writing code to simulate people then youre doing it wrong and you need to reconsider your approch to the problem

  4. Alex

    @pron

    No two actors are the same: http://www.planeterlang.org/en/planet/article/Erlang_Doesnt_Fit_The_JVM/ (an amusing read). This one is informative too (http://www.javacodegeeks.com/2011/04/erlang-vs-java-memory-architecture.html). Hopefully, I’m not banned as a spammer!

  5. MaggieL

    so… OO if you don’t know what you’re doing, FP if you do?

    Glad I’m working in Scala, because, as you say, it depends

  6. @yeah

    Glad that’s settled. Thanks for the stimulating retort.

  7. pron

    @Alex

    In the first link, all claims but 4 (lack of TCO) are not only untrue, but the JVM probably has better solutions for them than Erlang (and I really like Erlang, but the JVM is so much more versatile).

    As for the second article: lightweight threads in Pulsar consume less RAM than in Erlang (on the order of 400 bytes). As for the memory claim: it’s true, the JVM does have a single heap, but its many GCs are so advanced, that I’m not sure it compares unfavorably with Erlang.

    I will say this: the JVM would never offer as much process isolation as Erlang. But most applications that need, or can benefit from the Erlang model don’t need such strong isolation guarantees; on the other hand, many can benefit from the JVMs versatility and performance.

    Having said that, I think Erlang is absolutely brilliant. It is one of the two languages (the other being Clojure) that tackles head on what I think are some of the biggest problems in modern software engineering (unlike some other languages that pile on nifty compiler features as if the biggest problem in software engineering is low productivity or lack of ever-higher-order abstractions).

  8. jed

    What do you mean exactly by OO?

    I hear many comparisons of “FP vs. OO”, but where I can readily identify what FP is (programming with referentially transparent functions), OO is a fuzzy term that may or may not include any number of features.

    For a much better explanation of the problem, see Runar’s http://apocalisp.wordpress.com/2008/12/04/no-such-thing/

  9. @jed

    My post definitely didn’t address the points brought up by Runar nor do I think I’m (in general) equipped to tackle them at all. Perhaps in a later post I’ll talk about the-thing-that-might-be-oo-but-is-not-definable-but-that-I-find-useful-for-simulation. In fact, I propose that as the paradigm’s name. ;-)

  10. I think a hybrid of a classical or prototypical object-oriented language with strong functional constructs is the best approach. I think Python and actual ecmascript 5 both nail it.

  11. Would you be able to expand on this post a bit? I’ve really wanted to hear this kind of comparison from people with experience in both OO & FP.

    “simulating people” – to me the only apps that simulate people are games or crowd-behaviour models etc. Is this the what you mean, contrasting with User classes in a CRUD apps which aren’t simulation (“data about people”)?

  12. Andy

    @pron

    I highly doubt you have run fprof on your large erlang system. Please do so and you will most likely find that erlang performs favourably. It is telling that this is a widely acknowledged issue on the JVM solved by commercial products like zing, although no one ever mentions it as an issue in erlang.

    Unless pulsar reimplements Thread, how can a pulsar actor guarantee not to block an OS thread?

  13. WhiteSkull

    It depends, as one says here, will depend on what you want to address. The language, device capabilities … It has more code and more time creating classes, it is faster to write a function and call it. On the other hand, the OO is more orderly, everything has a hierarchy … are unordered functions. I honestly, I do not lose sleep OO or FP

  14. I am big fan of combining FP and OO, particularly in Python.

    Often, when working on a problem, I’ll start with a simple imperative solution based on top-level functions. Then, as the domain creeps ever larger and passing around values becomes awkward, I factor in a basic object model with only essential behavior moved to methods, while the bulk of processing remains on the functions.

    Finally, as recurring algorithms emerge, I start to refactor them into general implementations, customizable through object or function arguments. Eventually, most of my code is collected into highly general “portfolio” functions, while the “real” functions are mostly constructed by mixing and matching those. As a side-effect, closures and lambda functions abound.

    This approach doesn’t have much of the obsessive recursivity found in classical functional programming (although I’ve at times marveled at the mind-blowing length of the function invocation chains it produces), but it does rely on the first-citizenship status Python grants to functions – in fact it wouldn’t work otherwise. It isn’t “pure” functional, as it isn’t “pure” OO either; but it enables widespread code reuse, naturally leans toward cohesion & loose coupling, and is highly productive.

    Purity is a fool’s errand. Just as it’s not practical to have a “pure” object-oriented language (even Java has allowed for something akin to top-level function with static methods and imports), successful functional languages (and programmers) have to compromise in order to accommodate its design ambitions and the pragmatic needs of daily coding.

  15. You might check out “ClosuresConsideredHarmful” on the WikiWikiWeb and ObjectOrientedRefactored.

  16. foodbaby

    Can you clarify more what you mean by, and the differences between, simulating people vs data about people?? Thanks :-)

  17. RE: “Whenever I write some code to simulate people then object-oriented programming seems to work best.”

    Functional Programming can work pretty well for simulations. A person is modeled as an FRP or co-monadic behavior, and the environment/world is modeled as an even larger behavior, and you insert multiple instances of the former into the latter.

    :)

    Where OOP and Actors shine is not “closed world” simulations, but rather the “open world” ones, where participants (observers, extensions, agents, services) can come and go at runtime and have a lifespan independent of the functional computation. FP and FRP don’t have a good answer for those without (essentially) modeling pervasive support for effects.

  18. @dmbarbour

    Thank you for your comments.

    not “closed world” simulations, but rather the “open world” ones

    That’s a good point and a distinction that I should have made. I don’t have much experience in closed-world sims except for some DEVS sims studied many years ago, so I will have to try and get back into that headspace and reason about your points.

Reply to “FP vs. OO, from the trenches.”