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.

Gorilla holding a banana

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.

More programming posts

15 thoughts 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. 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. 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. 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.

  5. 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.

  6. 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.

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

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

  9. 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 ( for how to do this in Java, easier to do this in Scala and Groovy.

  10. gorilla.getBanana()

    Context is a matter of perspective.

  11. I’ve found that throughout my career there isn’t really a whole lot of reusable code outside of utility classes. This is because every client has vastly different business requirements and the bulk of the code that gets written is centered around those business requirements. What I have found to be reusable are different techniques and methodologies that get built up over the course of a project that can be then applied to the next one.

  12. Stefan Houtzager

    Have you read Erik Meijers
    I agree with what he says. “There is a trend in the software industry to sell “mostly functional” programming as the silver bullet for solving problems developers face with concurrency, parallelism (manycore), and, of course, Big Data. Contemporary imperative languages could continue the ongoing trend, embrace closures, and try to limit mutation and other side effects. Unfortunately, just as “mostly secure” does not work, “mostly functional” does not work either. [..]”

  13. The difference between functional and object-oriented programs is how wide your interface becomes. Your interfaces will be narrower with object-oriented programs. Your interfaces will be wider with functional programs. Many functions are just interchanges between the function that ultimately holds the data and the functions that use the data so many interfaces from where the data is held.

Comments are closed.