FP vs. OO, from the trenches

http://blog.fogus.me/2013/07/22/fp-vs-oo-from-the-trenches/

by llambda • 13 years ago

162 126 13 years ago

blog.fogus.me

MatthewPhillips• 13 years ago

Fogus makes the same point in Functional JavaScript (I highly recommend it).

mef• 13 years ago

Anyone care to expand on the reasons for the guideline?

mhaymo• 13 years ago

Without such reasoning, this article is kind of worthless, and I'm not sure how it got to the top of HN.

RogerL2• 13 years ago

Functional programming works great for processing data - you don't want to change the data, and there isn't a lot of state. You largely write various transforms and filters, which is right in FP's wheelhouse.

On the other hand, simulation is quite state-full, often has tons of little details that you don't want to expose to the world (encapsulation), the thing that you are simulating usually has a collection of varying behaviors that you can represent via polymorphism or composition, they have attributes, and the 'engine' is often easier to write if you use dynamic(virtual methods)/static(generics)/duck polymorphism to get your things to do their, well, thing.

Which is not to say that either is undoable or really hard in the other paradigm, but if I am simulating something I am often thinking of 'objects' and doing things to them; the OO paradigm helps you program about that in a very expressive way. Ditto for FP and functional programming - I'm thinking about filtering and transforming data.

That is just my view of the author's article, with a caveat. I've seen terrible, beastly simulations done in OO that basically thought that single inheritance is how you spell OO. A single type hierarchy bites you so hard: 'Oh, I'm make everything a widget with draw/eat/process/whatever methods'. Then requirements change, and widgets in this subtree need to do something you thought only widget in that other subtree would do, next requirement has you needing to reflect on who can do what, and so on. You end up with a huge Blob object at the top of your hierarchy, or you endlessly end up with huge blocks of RTTI/reflection to figure out what kind of thing you are dealing with, or otherwise try to work around the problem that the world is not easily decomposed into a single hierarchy.

In practice I find all of this terribly reductive. Need some small thing whose behavior varies in well defined ways? Use polymorphism. Have a bunch of stateful stuff that you need to keep track of? Encapsulation is nice. Want to perform some operation on a large collection of data? Look to transform(). Need to make a lot of inferences and conclusions? Perhaps logic programming will work there. Need to provide a framework where people can build larger systems? Hopefully you are using component or services based ideas. And so on. A programmer should have a bunch of tools handy, and use the best one for the job. On the other hand, just about every person I interview opines that we should inherit for re-use, and I silently despair.

bsg75• 13 years ago

Having seen some in the MS camp suggest that F# is a good candidate for data work (vs C#) for similar reasons, are there languages in the cross platform crop whose strengths lend towards data (string) processing (vs app development)?

OCaml becomes interesting given the above due to syntax similarities. Scala/Clojure due to Java library support(?). Haskell because it seems to get a good amount of attention.

chongli4• 13 years ago

Have a bunch of stateful stuff that you need to keep track of? Encapsulation is nice.

I think this one is open for debate. There are other models for managing state which make things simpler to reason about than classical OO with encapsulation. One such example is Clojure's epochal time model.

http://www.infoq.com/presentations/Value-Values

bluehex• 13 years ago

This post is nearly devoid of information. At least an example of what the author means by modeling data about people v.s. stimulating people might have helped. Most problems I encounter don't relate to people at all but maybe I'm to just replace 'people' with 'things'?

city414• 13 years ago

I'm puzzled why this is currently at the top of HN. I'm assuming the author must be someone well known who I've missed out on, as that seems to be the only way posts devoid of value push forward around here.

dysoco• 13 years ago

Indeed, he's a famous opensource developer and wrote some books, including "The Joy of Clojure" one of the most famous Clojure books out there.

fogus7• 13 years ago

I posted it. Someone passed it to HN. People hit an arrow pointing upward. That's how anything gets to the top of Hacker News.

eieio2• 13 years ago

It's definitely a very small post(I expected more when I opened it) but I assumed that people upvoted it because they were interested in the discussion that it would produce. There's definitely plenty to say on the subject of functional vs object-oriented programming, even if this article doesn't happen to say much.

MichaelAza• 13 years ago

A meh post from a (usually) great author. A shame.

reader50002• 13 years ago

I don't think the author has control over which of his blog posts hit HN front page.

eitland3• 13 years ago

Why exactly is that a shame?

Especially considering how many don't ever come around to publishing anything?

eitland3• 13 years ago

Simula is regarded the first object oriented language and the purpose of the language was simulation.

The idea of using an object oriented approach to simulation goes back to at least the sixties.

The way I read his post is that working on sets of information tends to be easier in functional languages event based simulations tends to be easier in object oriented languages.

badman_ting• 13 years ago

Agreed - not much here.

lispm2• 13 years ago

'stimulate' people? How about some tea instead of OOP?

Mordor• 13 years ago

Long story short: the next big thing is a language which mixes both FP and OO.

ams6110• 13 years ago

That would be most languages in wide use today.

ihsw• 13 years ago

Personally the only point of contention with FP vs OOP is immutability, or more directly managing state. The distinction between 'simulating people behavior' and 'measuring people behavior' is probably intentionally vague to spur the imagination, but it's quite apt.

Many languages implement multiple flexible looping/filtering structures to discourage shoving everything into for/while loops (which are susceptible to confusing and messy continue, break, goto, yield statements strewn about). Furthermore the rationale behind Clojure[1] is stateful objects are a new kind of spaghetti code, and managing state across scopes requires breaking mental boundaries.

[1] http://clojure.org/rationale

platz3• 13 years ago

Then your next big thing is (especially) Scala

saosebastiao• 13 years ago

Or Rust. Or D. Or Ruby. Or C#. Or Dylan. Or Lua. Or OCaml.

Lots of languages have concepts from multiple paradigms. What is the correct mix of concepts is up for debate.

I honestly believe that Rust has the potential to become the perfect mix for me, but OCaml and D are pretty good second places with the benefit of exponentially greater stability/maturity.

zeckalpha• 13 years ago

Or OCaml.

chongli4• 13 years ago

What, like Lisp?

jonsen2• 13 years ago

The next really big thing will be a language that does not mix things up.

I.e. a language that keeps a clean orthogonality between the three dimensions of a program --state, functionality, and event handling-- not favoring one over the others. The hard part is to make hierarchical modularization mechanisms work simultaneously along all three dimensions.

evincarofautumn2• 13 years ago

Why do we need hierarchy? Grouping makes sense, but deep nesting often looks misguided from where I stand.

fogus7• 13 years ago

I'm not sure I would say that. There's no reason that a single language needs to solve both problems.

pnathan• 13 years ago

Actually, I would disagree with you, based on (1) my personal work and (2) discussions with a variety of other people as I thump the "not all programming needs to be imperative languages" drum.

First, working in a single language allows you to accumulate what, for lack of a better word, I call "IP". Components/libraries/frameworks; a body of work. Having a single language gives you the leverage of previously written code solving prior problems in a debugged fashion.

Second, having a single language allows easier social operation; people can review each others work, a common body of knowledge can form around the language under common use which is difficult to maintain for multiple languages simultaneously.

Third, having a language which is a bit of a melting pot allows idioms to be used in which people are comfortable with their specific idiom - OO/FP, etc.

wedesoft• 13 years ago

One can implement OO using closures: https://github.com/alvatar/code-ttrs/blob/master/scheme/pure...

pooya72• 13 years ago

Isn't that what Scala is striving to do?

huherto• 13 years ago

I don't think you have to choose one or the other. They are not mutually exclusive. Furthermore, I still use Structured programming ideas along with OOP and FP.

alipang• 13 years ago

Kinda weak post, though what he said in point four vibes with me, where he argues for using OO on the lower level with a functional API / abstraction.

This is a really underutilized design strategy. Much too often architecture is discussed in OO vernacular, and as a result is made much too complicated. I think we'll come to see OO as a low-level technique more and more.

ajanuary• 13 years ago

Gary Bernhardt has a screencast [1] on DAS that proposes the opposite architecture of functional core, imperative shell.

[1] https://www.destroyallsoftware.com/screencasts/catalog/funct...

waxjar• 13 years ago

Four footnotes on a two paragraph article?

Guidelines seem sensible though.

reeses2• 13 years ago

Think of it as four powerpoint slides with one "source" each.

reader50002• 13 years ago

If you're doing something like agent based modeling, FP is great since you get snapshots of your simulation "for free".

And whats the difference between e.g.

agents[0].location.x += 5;

versus

(update-in agents [0 location x] + 5)

williamcotton4• 13 years ago

If you have a simulation, where the outcome is not known and individual Objects are keeping track of their own data and behavior...

VS.

...you already have data about a set of things and those things aren't going to be changing their own data.

Think, Video Game VS. Data Visualization

williamcotton4• 13 years ago

If I have a run loop/game loop, I always use OOP.

I'm curious, has anyone ever implemented a run loop in a functional style? I know there are recursive approaches to passing the time deltas and what not, but it seems rather difficult to make video games with a purely functional approach... Can anyone offer any insight?

klibertp• 13 years ago

It is hard. At least that's what I read in:

http://prog21.dadgum.com/23.html

EDIT: but not that hard, according to http://prog21.dadgum.com/37.html ;)

seanmcdirmid2• 13 years ago

FRP can supposedly handle stepped physical computations.

wonderzombie• 13 years ago

https://en.wikipedia.org/wiki/Entity_component_system http://www.gameenginebook.com/gdc09-statescripting-uncharted...

Caveat lector: I'm not familiar with the current state of the art in gamedev, so this may not be new or interesting.

The gist of this is that you prefer composition over inheritance, which is a bit more functional than an OO inheritance hierarchy. It's not strictly functional and it's definitely not purely functional. But it's a step in that direction, as it lends itself to viewing your system as a series of transformations over data rather than a system of actors.

The second piece is also possibly only tangential, as it does have state. But it shows an interesting way to incorporate concepts germane to FP like continuations, and it does use a homegrown Lisp as its scripting language.

augustl• 13 years ago

One insight is that functional programming and pure functional programming are very different beasts. As an example, Clojure does not aim to be pure, Haskell does. In Clojure, the focus is on immutability, and state is modeled as a succession of immutable values. Example: the employees in a company is represented as an immutable value. A place (a ref) stores the current immutable value, and you can always ask this ref for that value, and set it to a new one. But the value itself is always immutable. In Haskell, everything must be pure, and uses monads to models things such as random number generators, I/O, and other side effects.

weavejester• 13 years ago

I've recently experimented with using functional reactive programming to handle the events of a game. I've found it allows for a greater degree of abstraction than an event loop with callbacks, in the same way that higher-level functions like map/filter/reduce provide an abstraction over iteration.

lispm2• 13 years ago

I would propose the opposite.

btilly4• 13 years ago

I have a version of this that I've used for years. Objects make good nouns. Closures make good verbs.

Software organized around nouns looks different than software organized around verbs. Not better. Not worse. Different. Use what is appropriate.

guelo• 13 years ago

A concept from a classic Steve Yegge rant, http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

btilly4• 13 years ago

He said it better, but I said it before he did: http://www.perlmonks.org/?node_id=318563.

The root of that discussion was http://www.perlmonks.org/?node_id=318257 which I think is interesting in its own right.

dustingetz• 13 years ago

"Objects make good nouns"

most 'objects' as they exist in today's OOP have methods, which makes them both nouns and verbs. Idiomatic code in most of today's mainstream OO languages doesn't make heavy use of closures, mostly only Javascript.

Anyway, the closures vs methods debate has been going on for decades is not a closed topic[1], and the answer certainly depends on the language you're using.

[1] http://www.c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

samatman• 13 years ago

I don't believe this is a nitpick, but fully encapsulated OO provides only nouns and verb phrases that have a pre-specified noun. This is different from data structures (nouns) with collections of functions (verbs) that can act on many data structures in a consistent way.

btilly4• 13 years ago

What you say works well if you already have your data nicely divided into different kinds of objects. However a useful technique with closures is a dictionary of closures allowing you to map things that may be of the same type to different behavior. Wrapping those in objects so that you can use method dispatch can be a lot of useless work.

As a concrete example I point you at http://www.perlmonks.org/?node_id=34786 where I demonstrated how to take transform a markup language into HTML through the technique of grabbing a token, then passing to a closure that is associated with that token to consume a bit of the document. Porting that closure-based code to an OO style would be a nightmare.

wellpast• 13 years ago

Actually there is better and worse.

Verbs/functions are easier to compose and recompose; they're easier to reason about (there is no "state" in verbs; verbs are declarative.)

Nouns (assume: with behavior; not just data -- otherwise you are in FP-land again) are harder to compose and recompose, harder to reason about (state transitions).

Consider calculating age. Assume general FP and general OOP ways of solving the problem. Then:

ageOf(p)... ...ageOf() can potentially be applied (or modified to apply) to different value types. ...self-evidently does not mutate p or cause a state transition (assuming FP).

p.ageOf() ...can only be applied to value types/classes that support that operation. ...may or may not mutate p/cause a state transition of p.

One is much easier to reason about and reapply when the world changes.

btilly4• 13 years ago

For a start when we're talking about closures versus objects, we're not necessarily talking about true functional programming. Closures can have and manipulate internal state. Pretending that they don't ignores real world usage where they do.

However let's limit ourselves to functional techniques. Whenever someone talks about something in the very abstract and says "easier to reason about" I mentally insert "for you". Certainly it isn't true for everyone or every situation.

A basic principle in programming is that starting at the hardware level we build abstraction layers that let us think about things in higher level ways, hopefully ultimately in a way that matches the terms that the end application uses. End applications have concepts like account balances, user status, and other such stateful pieces of information. If you're going to have the state, workaround that you pretend you don't, you will cause confusion. Pick your favorite 5 Monad tutorials for proof.

Consider as an example the use case, "Provide a form to let us mark spammers, and block them from our site." For all the theoretical advantages of avoiding state, this is going to be easier to model in a system where users have a piece of state known as is_spammer.

_random_• 13 years ago

Or you could pick something like C#/F# and use both approaches harmonically.

abecedarius• 13 years ago

The lambda calculus was the first object-oriented language. http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf explains this and proposes a crisp distinction between OOP and abstract data types.

davidcuddeback• 13 years ago

I read that paper a couple years ago and it changed the way I see object-oriented programming. All of a sudden, the dependency inversion principle just clicked.

I hope I hit the upvote button instead of the downvote button. I'm typing this on a shaky train and my browser will only zoom in so far.

doorhammer• 13 years ago

You know what has a lot less information than the blog entry? All the comments about how little information it has.

Well... and this post, now.

I always come to the comments to throw a little balance or extrapolation into my reading, and its disappointing to find people mostly just complaining.

Got a few interesting nuggets, though. So not all bad.

the1• 13 years ago

is facebook.com about people or simulating people?

jb55• 13 years ago

I've always viewed OO as a nice optional UI for most programmers. Given an object to mutate and call methods on seems to click for most people. I tend to go for a more functional style internally for the composibility and maintainability properties you gain.

babarock• 13 years ago

I'm a bit confused.

I always thought that FP and OO were orthogonal concepts and never considered them mutually exclusive. To me, the antitheses of FP would be imperative programming. Maybe I'm missing something?

CLOS, OCaml, Scala, I can think of many examples of languages that include components of both FP and OO. Or maybe we're simply considering that OO means this special paradigm used in C++/C#/Java (that really only claims to be the true and only OOP by the commercial entities backing these languages)?

PS: I googled around a bit, this Clojure article [1] seems relevant.

[1] http://clojure.org/state

fogus7• 13 years ago

never considered them mutually exclusive.

I never implied mutual exclusion.

pr0filer__• 13 years ago

I'de say versus implies mutual exclusion

cygx3• 13 years ago

Actually, FP and OO are mutually exclusive to some degree:

OO comes from the imperative end of the spectrum (after all, objects are an abstraction over mutable state), whereas FP comes from the declarative end (a pure function is a relation between sets and mutability is a foreign concept).

However, most programming languages are impure and support both paradigms, so you can get away with thinking about OO and FP as orthogonal ways to reason about and structure your code; language syntax and semantics may of course favour one concept over the other...

bad_user2• 13 years ago

OOP is not about hiding / dealing with mutable state, although it can be used that way, but that's a perverted idea of what OOP is.

OOP is about subtype polymorphism [1] by means of runtime single-dispatch [2] and modularity, as in abstract modules or components that help with decoupling, a notion supported explicitly by SML, or exemplified beautifully in the Cake-pattern used in Scala.

[1] https://en.wikipedia.org/wiki/Subtyping

[2] https://en.wikipedia.org/wiki/Single_dispatch

andolanra2• 13 years ago

You can have pure objects, depending on how you define 'object'. If your conception of object-oriented programming involves mutable objects changing state in response to messages... then yes, FP and OO are strongly at odds. However, if your conception of object-oriented programming involves information hiding via packaging functionality into units called 'objects' that expose public operations which are written in terms of some manner of implicit or explicit 'self' parameter... why not? That's what OCaml has, after all, and there was even an O'Haskell at one point[1].

Unfortunately, discussions on the merits of FP versus OOP tend to be asinine just because every participant has their own personal definition of both 'functional programming' and 'object-oriented programming', often based on implementations in a particular language. How does Haskell's idea of FP compare to Java's idea of OOP? What about Agda versus Python? Erlang versus Smalltalk? Does FP require purity, or types, or pattern matching?[2] Does OOP require inheritance, or private members, or classes? Without knowing these details, who can even tell what schools are being advocated or why?

[1]: In OCaml, objects can contain mutable values but they must be explicitly marked as such. An object with no mutable values is effectively a pure object, and there are many good reasons to use such an object—analogous objects are useful even in other languages not traditionally considered functional, e.g. new PureObject().someMethod().otherMethod() creates a series of objects which themselves needn't expose a stateful interface at all.

[2]: I'm not asserting that FP requires these things, but I have seen discussions where people clarify that languages can't be functional without function composition or algebraic data types or typeclasses or what-have-you, usually working off an informal definition of 'functional language' based on their language of first exposure.

asdasf2• 13 years ago

The antithesis of FP is imperative. And OOP is imperative. Imperative programming encompasses both procedural and object oriented programming. Those are simply two different ways to structure an imperative program.

cygx3• 13 years ago

I'd hesitate to call imperative the antithesis of FP:

It's imperative vs declarative - FP is on a different level of abstraction, as a sibling to, let's say, logic programming.

eternalban• 13 years ago

FP makes an excellent backend -- architecturally speaking -- for OO-, REST-, front-ends, and a most excellent front-end for Relational systems. (Haskell, for example, would be a dream language for sprocs.)

gruseom• 13 years ago

I find this post suggestive. The title—"from the trenches"—makes the important point that this is a reflection from experience on what seems to work best where. That's more valuable and harder to come up with than it sounds, because if you identify with a paradigm then you don't easily notice it getting in your way.

I would like to hear a more detailed treatment of the distinction between "dealing with data about people" and "simulating people". If these overlap (and surely they do), then you get into a circularity where your favorite paradigm leads you to see a problem its way, just as much or more than the problem nudges you toward a paradigm for solving it.

On the other hand, my experience matches the OP's that OO's sweet spot is close to its origins in simulation--where you have a working system that exists outside your program, your job is to model it, and--critically--you can answer questions about how it works empirically. When you aren't simulating anything, OO is cumbersome because it requires you to name and reify concepts that become "things" in your mind; these ersatz "things" continually draw attention to themselves and get between you and the problem.

pdog• 13 years ago

For actor-based programming in Clojure (complete with real lightweight processes, selective receive and an Erlang-like API), look no further than Pulsar:

http://puniverse.github.io/pulsar/

jacquesm2• 13 years ago

For all those hating on this blog post: It's short, but it doesn't have to be long to be useful, and apparently it is useful given a substantial chunk of the comments here. If it wasn't news to you then ignore it, otherwise appreciate that not everybody is quite as enlightened as you are.

HN has a tremendous reach these days, from pioneers in the field to total (and often clueless) newbies. Fogus felt compelled to write down his thoughts, someone else saw fit to post it and as of this moment 100+ people thought it was useful enough to vote it up. If that's not validation enough for you then remember that time when you spent half a day tracking down an endless loop and you had to ask a more seasoned programmer to point it out to you.

Fogus is a respected member of the community because he tends to write down what he thinks in a way that others much further down on the totem pole can grasp it too, his articles are not upvoted because he's 'well known' but mostly because people find them useful.

If you feel like this article was 'devoid of content' or whatever slur you feel like directing at it then please, write a better one.

semiprivate2• 13 years ago

That's not a real argument. You're essentially saying "respect because I said so."

The irony is your argument is just as flimsy and opinionated as everyone else's.

This article is devoid of content AND is written by a respected member of the community but neither of those things make it worth reading.

The great moral of the story here is, if you let the internet bother you, the internet will definitely bother you.

jacquesm2• 13 years ago

Content is not determined by the quantity of words on a page.

Some of the deeper links between linguistics and programming can be quite eye opening and it does not require a large number of words to put those down. If you find one of these, especially through your own work (as in 'from the trenches') then that should carry some weight with you.

If you're doing this independently and re-discovering something that apparently a lot of people such as you have already found out or learned about elsewhere then indeed it is devoid of content. But I'll bet that it wasn't the case for the majority of those that read it.

Lots of programming wisdom is so terse that we have acronyms for it (DRY for instance), that does not mean there is no content there.

Anyway, enough said, I think it is worth reading, and worth 'grokking' for want of a better word, in case you had not already discovered this. Naming stuff is one of the harder things in programming, that different streams of programming should lead to different groups of words being used to describe the code should probably come as no surprise and yet I find myself amazed that there are such deep connections.

lazyBilly• 13 years ago

I don't have much good to say about that particular article, so I will say nothing.

The rest of his blog I found fascinating, however, and I'll be reading through it with great pleasure.

michaelochurch3• 13 years ago

One thing that bugs me in the imperative vs. functional debate is that we (functional programmers) often show people a side-by-side comparison with 20 lines of imperative code, 6 lines of functional code, and say, see, the functional code is so much better! Well, to us, it is. Filtered through our biases, it's much more intuitive.

I think we're wrong on one thing. Personally, I think imperative code is more intuitive. It matches how people think of operational behaviors.

For a 20-line program that will never grow, I'd rather see an imperative straight-line solution. FP wins when things get a lot more complex: various special cases and loops within loops. Stateful things compose poorly. Debugging a 300-line inner for-loop is no fun. Functional programming, done right, means people factor long before it gets to that point.

Factories and Visitors prove what hellishness comes into being when one doesn't have those functional primitives, but this does not make the superiority of FP intuitive or obvious.

Now, OO is so variable in definition that it's very hard to know exactly what people mean. There's the good OOP (Alan Kay's vision; encapsulate complexity) and then there's bad OOP (overuse of inheritance, auto-generated classes, Factories and Visitors).

One can conceive of core.async as an OOP win in Clojure; lots of complexity (macroexpand a go block at some point) is being abstracted behind the simpler interface of a channel.

chris-martin4• 13 years ago

Personally, I think imperative code is more intuitive. It matches how people think of operational behaviors.

The masses agree with you, apparently. That's why they sit in their cubes all day writing the same god damn re-implementation of map over and over again

    List<String> result = new ArrayList<>();
    for (int i = 0; i < list.size(); i++) {
        result.add(input.get(i).toString());
    }

instead of

    input.map(_.toString)

because functional programming is confusing.

pjmlp2• 13 years ago

Quite true.

I still don't understand why recursion is confusing to learn, as for me it was obvious from day one. Then again I am good at maths.

Additionally, I had lots of fun doing Caml and Prolog when I was at the university.

So even though I tend to do the typical boring enterprise JVM/.NET/C++ stuff, I do welcome the FP contamination of those ecosystems. :)

However on my last project, I had to rewrite some LINQ stuff back to plain imperative code, because few people on the team could manage it (LINQ). :(

michaelochurch3• 13 years ago

That's another problem with imperative programming; it tends toward DRY violations.

The solution using map is more intuitive, once you know what map is.

I agree with you, as well, that the functional style should be used far more often than is the case. I just think that one shouldn't assume that our way of doing things is inherently more intuitive, even if it is most often better.

FP vs. OO, from the trenches

Related Stories