You wanted a banana but you got a gorilla holding the banana

Joe Armstrong, creator of Erlang, on software reusability.

I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.

Source: Coders at Work. Emphasis added.

I do most of my work in object-oriented languages and I don’t see that changing any time soon. I’m more interested in functional techniques than functional languages: using pure functions, using functions as arguments and return values, etc. As Joe Armstrong says, such code is easier to reuse. If you want to reuse (or test) a functional banana, you don’t have to set up a stateful gorilla to hold the banana first.

Related posts:

Opening black boxes
How to become a good programmer
Where OO has succeeded most

Tagged with: ,
Posted in Software development
12 comments on “You wanted a banana but you got a gorilla holding the banana
  1. “I’m more interested in functional techniques ” too, but are these techniques more effective in functional languages? I mean, why bother creating different programming languages to fit different paradigms?
    And I’m sure, “you don’t have to set up a stateful gorilla to hold the banana first.”
    Inspiring post, thanks.

  2. Mike Swaim says:

    I don’t care for “dogmatic functionalism”, either. Fairly often, I’ll have to build useful objects by processing them in multiple passes. If objects are mutable, this is straightforward. If they’re not, then you either have to jump through hoops to build them right the first time, or you have an unnecesary number of temporary variables.
    Also, sometimes it’s really useful for your “function” to be stateful, if what it’s doing is expensive. Chris Wakefield gave a talk about some code that his team was working on, which took hours to run on decent data sets. They altered it so the piece of code that did the heavy lifting used memoization to avoid repeating expensive calculations, and the run time went from hours to seconds. Big improvement!

  3. John says:

    The space of programming languages and styles is more complex than functional or object-oriented as yes/no options. Languages make functional programming or object-oriented programming convenient to varying degrees.

  4. Pascal says:

    There are no bad programming languages. There are only bad programmers.

  5. Sol says:

    I feel like I’m really missing the point of the quote. I mean, a major part of the point of object oriented programming is to bundle the explicit environment of your functions in easy to (re)use bundles. If you’re creating an implicit environment for it them that you cannot easily track, you’re doing it wrong.

  6. gappy says:

    This post made me finally purchase Coders at Work on Amazon. I think that the advantages of mutability are greatly exaggerated. In my experience, a) copying objects and/or passing objects by value is most often not a bottleneck; b) stateful functions are not so useful, once you know enough functional programming. It’s just an emprical observation. I am sure that a game designer or someone coding discrete-event simulations will earthily disagree.

    Definitely once can adopt a functional or OOP style in many languages, although those are better learned and used in strict, single-paradigm languages first. Java is inherently object-oriented; Scheme is inherently functional. The interesting question to me is whether one should embrace a universal multi-paradigm language (e.g., Scala, C++) or rather a toolchain of languages with good interfacing capabilities, and well-defined paradigms; e.g., Clojure+Java rather than Scala, or C+LISP, etc. I have no experience with large projects, but it seems to me that exploiting the competitive advantage of single languages makes more sense, because multi-paradigm languages are usually easier to write in than to read. But then, the idea of using a single language for everything is very appealing.

  7. John says:

    gappy: Language barriers are also cultural barriers. Programmers who use different languages don’t speak to each other. I was dumbfounded when I first observed this; a VB programmer won’t even bounce high-level design ideas off a Perl programmer etc. So unless you’re working in isolation, there’s a benefit to keeping the number of languages in play to a minimum.

  8. Mike Swaim says:

    I’d agree that copying objects is usually not a bottleneck, and stateful objects usually aren’t needed. However, I’ve seen way too many examples of exceptions to make them general rules.
    I’d also prefer one multi-paradigm language rather than using multiple languages with different paradigms. It’s harder to maintain expertise in multiple languages, and limits your ability to move people around as staffing and requirements change. (And many of us are in environments where we have multiple languages already. In my work environment, we use Transact SQL, C# HTML and Javascript. I really don’t want to have to learn another language.

  9. Chris Barts says:

    Pascal: Really? Are you going to defend INTERCAL as a language as opposed to a joke?

  10. Mark says:

    In OO languages, once you give up mutable state and embrace higher order functions, you are well on your way to programming functionally. Most of the Java advice is, in effect, how to implement functional programming idioms. These ideas can be done in any language, they are all (essentially?) equivalent, but functional languages allow you to work with the language, rather than always using workarounds for deficient languages. See Functional Java (http://functionaljava.org/) for how to do this in Java, easier to do this in Scala and Groovy.

  11. Kristofer Spinka says:

    gorilla.getBanana()
    tree.getBanana()
    floor.getBanana()
    store.getBanana()

    Context is a matter of perspective.

  12. Andrey Lomakin says:

    Hi,
    Did you look at Qi4j ? It is the way to “get banana without gorilla” using OOP style – http://qi4j.org/.

4 Pings/Trackbacks for "You wanted a banana but you got a gorilla holding the banana"
  1. [...] 本文是从 You wanted a banana but you got a gorilla holding the banana 这篇文章翻译而来。 [...]

  2. [...] You wanted a banana but you got a gorilla holding the banana [...]

  3. [...] this kind of thing will quickly lead you to realize that the banana you’re interested in and the gorilla holding it are very tightly coupled. But now that we’ve determined that’s not the case, how do we [...]

  4. [...] doing this kind of thing will quickly lead you to realize that the banana you’re interested in and the gorilla holding it are very tightly coupled. But now that we’ve determined that’s not the case, how do we [...]