Ask HN: Relationship between OO and functional programming?

Rich Hickey has mentioned that abstracting i/o devices is an example of where OO can make sense. using OO properly requires a honed intuition about how to build large, stable software systems and see occasions where, in such systems, some component or aspect would truly benefit from a bit of OO sprinkled in. i think one great way to develop such an intuition is pick up a functional language and use it for a significant period of time (a couple years) -- because this let's you see how far you can get just by writing simple functions and passing around simple data structures without any classes.

One relation I feel is that OO stresses on behavior and data to be a part of a single entity. Functional paradigm asks to keep them separate, with immutable data structures being passed to pure functions that have the behavior.

Disclaimer: I am surely not experienced enough to give a highly informed opinion on the topic.

As I mention in the opening I do not think there is a strong dichotomy between functional and OO programming. I believe historical accident created "Objects vs functions", and by historical accident I mean Java. It is unclear to me why would you not allow to create plain simple functions and force everything in objects. Probably a misunderstanding of "everything is an object".

Famously Alan Kay emphasizes "message passing" as the key characteristic of object orientation. Because every discussion about OOP and functional programming eventually ends up talking about State as the main discussion point, I fail to note how a definition of OO based on message passing contrasts the benefits of functional programming around state management.

In fact the way I see it is that when we have more units communicating with each other they form a system that should be functionally pure from an external point of view but can be OO in its internal implementation.

EDIT: Continuing my train of thought: the problem with OO in it's current common form is that objects often/always leak details about their state. So you have a tuple (state, [actions]) where often using an action is invalid given the tuple's state.

eh when you get down to it they tend to be 2 extremes with most programing being somewhat in the middle, there is a great article [0] that discusses the absurdity about talking about object oriented program by comparing it to talking about 'pants oriented clothing' in that it misses the big picture

[0] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

This is a really interesting question and much work has been done.

For a long time, lambda-calculus has been seen by a lot of programming language researchers as the foundation of programming to which every other paradigm has to be reduced. This research tradition produced much work on encoding object orientation (whether class-based or object based) into lambda-calculus. Ideally such encodings should be sound and complete. That has proven difficult. In parallel, functional languages acquired OO extensions. The first serious implementation to make this (sort of) work was OCaml. Arguably, all that work wasn't quite convincing. Eventually, it became clear that lambda-calculus isn't the basis of all other programming paradigms. Instead people tried the reverse: encoding lambda-calculus into object-orientation.

Scala really nails this, and validates your intuition that there isn't a dichotomy. Instead FP is a special case of OO.

If you want to understand the relationship between OO and FP there is no better way at this point to learn Scala and study how lambda-calculus (both at program and type level) is encoded into class-based object orientation.

   a method on an object is simply ...

   counter-example in mind?

They are orthogonal. Program in Scala and do both.

http://www.scala-lang.org/

Free course(s):

"Functional Programming Principles in Scala" https://www.coursera.org/learn/progfun1

"Functional Program Design in Scala" https://www.coursera.org/learn/progfun2

(There are two more free courses in the "specialization" - only the certificates and the capstone project cost money - original announcement http://www.scala-lang.org/blog/2016/05/23/scala-moocs-specia...)

Just a bit of a fun post on the subject, I quite like this koan about OO vs Closures [0]:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.

I was surprised at having come to a similar understanding after implementing a very basic OO system in Scheme some years ago.

[0] - http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

I like Michael Feather's quote https://twitter.com/mfeathers/status/29581296216

OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts.

I think they can be used in a complementary manner. One area where functional thinking can be a benefit can be in code that is tested with a lot of mocks. Instead of having a bunch of objects that mutate state and that need to be mocked out, model that part of the program as a series of pure function transformations of data. It will be much easier to test and reason about.

In the past five years, I've written C#, Ruby, and Javascript in a style I'd describe as "OO, but with a heavy functional accent"; it might even be fair to call it "object-functional".

A few little things I've identified that I do, that aren't totally mainstream:

- Don't reassign parameters, in fact, don't reassign things at all, if you can avoid it; show your work. It makes for more expressive code, and you'll have fewer bugs.

- Think of your code as doing "evaluation", not "computation". Code should take a bunch of inputs, do some stuff to them, and then return an "evaluated" response, vs. the viewpoint of "doing a procedure".

- Try not to make functions side-effecting. Avoid "void" unless you really need it, and really, really avoid distant side-effects.

- Don't be afraid to return a new object that seems "large" from a method. If you do it right, you'll mostly be copying references anyway which is pretty cheap.

- Share data liberally by reference all over your code.

- Don't be afraid to use a bit of recursion.

On the other hand, I'm not afraid of a little grubby OO now and then, especially when dealing with I/O, file handles, network streams, etc.

All to say, I think the two styles are about 90% compatible but there are some parts that don't mesh well. I'm not afraid to mix them, though.

Stuart Halloway has a great talk on this called "Simplicity Ain't Easy" [0] where he more or less states that a FP language like Clojure is basically a better designed OOP language, because FP is basically contains all its strengths (namespaces, abstractions and the like) and none of its weaknesses (e.g. uncontrolled state mutation) and you are able to select and use specific features you need to solve a specific problem, and not being saddled with every feature (including the ones you do not need to solve the problem at hand) at once.

[0] https://www.youtube.com/watch?v=cidchWg74Y4

For my money, OOP and FP are two axes on the same Expression Problem [0]. OOP languages, it's easy to add data on which a fixed set of functions can operate. In FP languages, it's easy to add functions that can operate on a fixed set of data. This is why there will never be a distinct "winner" between the two.

It's also why you have Greenspun's Tenth Rule, and why there is probably a Smalltalk corollary for FP languages. You eventually need to be able to solve both halfs of the expression problem.

https://en.wikipedia.org/wiki/Expression_problem

I wrote about this here: http://somethingdoneright.net/2015/07/30/when-object-orienta...

Comments welcome.

Well, OO tries to represent entities, and their state, via objects.

FP emphasizes immutability. So in OO + FP, objects are treated as immutable data. Functions create new objects instead of modifying the same object (avoiding side effects).

For convenience you can create functions to access parts of an object instead of creating new objects to achieve the same.

My take on this is that computation is the act of describing different states that the processor can be in - or describing the path from one state to the next.

I think an understanding of state is fundamental - one thing that brought this home to me was a talk I watched given by Sophie Wilson [https://en.m.wikipedia.org/wiki/Sophie_Wilson] in which she displayed an image of a cpu. The image showed a 'path' across the cpu that was the current state, the next image showed a different path describing a different state. The path was a lot like a bolt of lightening.

An understanding of functional programming (FP) matches this a bit more directly than OO as FP is a pipeline of functions that describes state change and it is easy to reason about the state at any point in the pipeline. OO represents a real world object so you are encouraged to think about the problem you are modelling rather than the how to represent different states. But obviously in the end they both describe state and logic that describes state transition.

I gave at talk about this at Scala Days NY, and I'll give it again in Berlin in a few weeks if I remember to actually book transport and a hotel. I'll just try and summarise here, because I don't have the energy or time to write out my talk :-)

I think FP and OO are fundamentally different in how they approach programming: the way they break down problems, what they consider to be good code, and so on. OO views code as small unit of encapsulated state communicating with one another. FP views code as a series of transformations. OO code is not good FP code, and vice versa.

On a lower level you can find many similarities. OO patterns are largely FP language features, from a time when knowledge of FP was not very widespread. At least five of the Gang of Four patterns are first class functions is disguise. Going the other way, a very typical pattern in functional programming is to build up a description of what should happen, and then have an "interpreter" actually execute that description. These interpreters often look like "coalgebraic" structures, which is an FP term for ... objects. Now isn't that interesting?

In summary, the techniques often look very similar if you squint, but the fundamental way they approach programming is very different.

That's a very quick sketch, which is somewhat hazy on the details. Apologies for the brevity and lack of nuance.

One way to start to think about this is the relationship between objects and abstract data types. These are both techniques for introducing data abstraction, but their approach is different and have different tradeoffs.

https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOO... is a paper that argues them as complementary to one another. It's worth reading in its entirety, but an excerpt from the conclusion:

A detailed analysis of the trade-offs involved must be made in order to choose whether an ADT or PDA ["object"] is better suited for a problem. Some relevant questions in this choice are: How likely is it that the system will be extended? Must the security of the system be preserved, even at the expense of extensibility? Is it possible the unforeseen interactions may be desired? Is the environment dynamically extensible, and must the additions interact in complex ways with existing code? How much efficiency is required? Is it likely that there will be a large number of binary operations with complex behavior?

In general, ADTs tend towards tight coupling, yielding more predictability, performance, etc. Objects tend towards looser coupling, allowing more flexibility and extensibility. This is a reasonable microcosm of the relationship between FP and OO.

The original idea behind OOP as articulated by Dr. Kay was that since general-purpose computers (Turing Machines) are powerful enough to simulate/approximate any process, then computers should be the smallest building block of a system (especially one that wants to scale -- recursion is awesome).

In general, objects are supposed to be processes (in the general sense, not necessarily OS processes). Some of those processes might be equivalent to full Turing Machines, but most will be much more limited; it just depends on what kind of formal grammar they recognize, which is key to understanding objects: They are just processes that accept some input and dispose of it as either code (something that is translated and executed) or data (something that is stored and forwarded). Crucially, in either case, objects do work by sending and responding to messages. This is why Dr. Kay says that the actual big idea of OOP is message passing[1].

Once I learned to appreciate real OOP, I realized that there is actually a natural simpatico between FP and OOP rather than a dichotomy. Consider that if you're doing real OOP, you're going to end up designing lots of little languages and then implementing interpreters/compilers for them. Well, it turns out that it's comically easy to build compilers and interpreters using statically-typed languages like ML (F# in my case).

Now days, I use F#, C# (immutably w/o setters), and SQL to simulate an environment that recapitulates what I think is the real power of Smalltalk/OOP: It can rather directly simulate the process of scientific progress itself. I now find myself designing classes that represent falsifiable statements [2] (e.g rather than a class 'SearchEngine', I'd have something like 'LowLatencySearchEngine'). Just as scientific progress is often concomitant with theories and models that have ever more symmetry, so it is the case with the graph of classes that describe my system: I somehow end up with fewer central points of failure. For instance, in the case of 'SearchEngine' vs 'LowLatencySearch' engine, the latter made it apparent that my class should be initialized with a set of search providers, and that it should keep latency statistics (thus being able to falsify the proposition). The end result is that the proposition represented by the class naturally contraindicates that I should rely on any one search engine.

There's a lot more to say about this, but the last thing I'll mention is that FP languages like ML teach you that there is a difference between a class and a (static) type. The big idea is that types correspond to logical propositions (the so-called Curry-Howard Isomorphism), but I naturally ended up there just by trying to more effectively simulate the process of science, which brings us full circle to Alan Kay's big idea: computers can simulate any process, they can even simulate better computers. I would argue the scientific process is the best computer of all.

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

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

I suggest people to take the pharo mooc on FUN. I have to admit, smalltalk has a very different flavour of OO. It's very tiny, and helps thinking in tiny reusable pieces of logic from objects to objects, not very far from function composition.

https://news.ycombinator.com/item?id=11690331

OO favors indirection to make code supposedly "maintainable." FP likes completeness in one place so code is more readable.

The biggest difference I've seen in my career:

- OOP code is usually separated and organized by the principal data it operates on, i.e. the instance of a class, and more specifically the instance's fields.

- FP code is usually separated and organized by the more abstract or philosophical responsibility of the functions, and they may not always share the same arguments.

Smalltalk has a lot of similarity with functional programming. Smalltalk's True and False instances are basically Church Booleans, and Smalltalk collections were processed frequently by passing a Block (like a first class function).

I joke that if Smalltalk were invented today, it would be called a "functional/object hybrid language for creating Internal DSLs"

I was reading "The Early History of Smalltalk" a while back (http://worrydream.com/EarlyHistoryOfSmalltalk/) by Alan Kay, and the thing that jumped out at me was goal-oriented methods (see the section "Object-oriented" Style). That is, when you are calling other code you don't tell the other code how to do something – and of course you don't go poking into what the other code "knows" (i.e., accessing properties on an object) – instead you say "please, make it this way". The code may succeed or may fail, but you aren't micromanaging the code.

From my time with Smalltalk I found this pattern quite remarkable, though also at times hard to trace. You'd tell an object to do something, and it might access some object it knows about, maybe do a test or guard, and then it would tell the other object to go do that thing. And the other object might in turn delegate, many levels deep. The result could be really incredible and compact, though it also felt like it wasn't actually easier to understand. Kind of Ravioli Code (http://c2.com/cgi/wiki?RavioliCode), though not the kind of modern Ravioli Code you might see because someone takes DRY too seriously – instead it reminded me more of a mathematical proof. Mathematical proofs are really cool, but they do not contain the information necessary to reproduce them; a mathematical proof is the result of studying and pondering and struggling with a problem for a long time until you reduce it to something compact and beautiful. The result seems magical, but in part because you threw away all the struggling that produced the result. That's what the core Smalltalk class hierarchy felt like to me; beautiful, maybe not reproducible, not always accessible. All of which is a critique of one place and time of code, and OO is bigger than that, but I suspect it's also some of the result of created goal-oriented methods All The Way Down.

Functional programming can also be goal-oriented if you can reify all your goals, because ultimately that which isn't reified (that is, made into data or state) can't be the result of a function. I don't have as intuitive a sense there, is goal-oriented functional programming an ideal people hold?

Another Smalltalk lens on OO is message-oriented programming, where you have a set of objects or actors which pass messages, but never directly "touch" each other, and in some sense objects are more autonomous than a conventional understanding of OO. This does not map well to functional programming – the purpose of messages to autonomous objects is to effect state, to make changes in the world. Of course that's the purpose of all programming, so it's not crazy. In some sense functional programming lifts the purposeful and useful outcomes of a program out of the programming, and into the environment. I would consider that a stronger contrast with OO.

See https://wiki.haskell.org/OOP_vs_type_classes

Here's a weird viewpoint: OO and FP only seem different because we serialize code through text.

Some languages (spoken languages) construct sentences Subject->Verb->Object, others Subject->Object->Verb, etc, etc. The underlying relations between the parts are still there (there's an isomorphism in the graph), but the projection onto linearized words just takes a slightly different angle.

In OO languages, we treat objects as the important component, and functions as their children: bar.foo(). In FP languages, we treat functions as the important component, and objects as data passing through: (foo bar).

There's no difference in the relations, it's just a different projection from high-dimensional computation-space onto one-dimensional text that causes all sorts of confusion.

That's not to say the difference doesn't matter: projecting computation in a different way frames a different mental model for the programmer that might help or hurt, depending on the specific domain and on the specific problem.

But I think there's value in trying to see the zen in OO's and FP's isomorphism, and practicing switching projections in the same domain as a problem-solving technique.

    myData = oldData.change().map(x => x+1).filter(x => isTrue(x))

   change(oldData) |> map(x => x+1) |> filter(x => isTrue(x)