14

In the book Coders at work Joe Armstrong stated that:

I think the lack of reusability comes in object oriented languages, not in 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

I do not quite get it here. If the problem is to get a banana, we can encapsulate all the logic behind the function 'getBanana'. How are monkey and jungle involved in this context. Could somebody write a code snippet that explains the problem in an easier to understand way, say, demonstrate the fact that the Banana object requires the Monkey and Jungle objects to be initiated, please?

6
  • see Discuss this ${blog} – gnat Apr 4 '18 at 8:46
  • Pity this got closed - it was yielding some good discussions. Look into first class functions as a starter. – Robbie Dee Apr 4 '18 at 11:23
  • 1
    @Euphoric Discussion type questions are actually allowed but which questions are subjective could be... subjective. – Robbie Dee Apr 4 '18 at 12:14
  • 2
    I believe that this interview was held before Joe Armstrong wrote his PhD thesis. While writing his PhD thesis, Armstrong learned about the real definition of OO, and realized that Erlang is actually thoroughly object-oriented, in fact, of all current mainstream languages, Erlang is probably the most object-oriented language! He wouldn't have made that statement in that way if he knew that Erlang was actually an OO language. What he is talking about is ambient authority, which has absolutely noting whatsoever to do with OO. – Jörg W Mittag Apr 4 '18 at 13:39
  • 1
    Hi, my question is about providing some sample code that helps me (and others) understand the problem better. Any code snippet that demonstrates the problem is acceptable, not just opinion. – Kha Nguyễn Apr 6 '18 at 7:28
16

He is hinting at a fact, that majority of real OOP programs don't respect separation of concerns. For example, you could have classes:

public class Banana
{
    public Monkey Owner {get;}
}

public class Monkey
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

If you use Banana, it is transitively necessary to also depend on Monkey and Jungle.

But I would strictly disagree that this is problem with OOP and that functional style somehow doesn't have it. This can easily be fixed in OOP with introduction of right abstraction.

The problem is more about developers not caring about separation of concerns. And I would not be afraid to assert that majority of OOP programmers are novices, while functional programers have some experience, that motivates them to properly separate their code.

Possible abstraction might be:

public class Banana
{
    public IBananaOwner Owner {get;}
}

public interface IBananaOwner
{
}

public class Monkey : IBananaOwner
{
    public Jungle Habitat {get;}
}

public class Jungle
{
}

This way, you know that Banana has owner, but it doesn't have to be Monkey. It can be anything. And it limits what can Banana do with owner to only operations defined by IBananaOwner, which simplifies reasoning.

13
  • And conversely while functional languages support first class functions out of the box - that isn't to say function X can safely be consumed by function Y without side effects. – Robbie Dee Apr 4 '18 at 10:15
  • Although you make an excellent point, I think you may be going slightly off piste here. The quote explicitly mentions the environment not how the code has been designed. – Robbie Dee Apr 4 '18 at 10:34
  • @RobbieDee The Monkey and Jungle are a environment for Banana. By introducting abstraction like IBananaOwner, the environment becomes explicit. And how this environment is designed is what his problem is all about. – Euphoric Apr 4 '18 at 10:36
  • You may very well be right but I can't help but think having read this among other things that the elephant in the room (to add another animal) is that the issue is in correct composition of the functions which functional programming, historically, has lent itself to more. – Robbie Dee Apr 4 '18 at 10:43
  • @RobbieDee You cannot replace what I written with simple function composition. At least not outside toy example problems. In practice, to fully replace OOP design, things like complex generics, type classes, monads and other are necessary. And that is just changing one kind of complexity for another kind. – Euphoric Apr 4 '18 at 10:46
15

Gorillas are not monkeys!

Leaving that aside, you answer your own question with "we can encapsulate all the logic behind the function 'getBanana'". All I want is a banana, but to get it I need to call getBanana on some object, eg an instance of the Gorilla class. That banana object then likely contains a reference to the gorilla it belongs to and that gorilla object will in turn have a reference to the forest it belongs to. So I ask for a banana, but encapsulated behind that is the entire jungle.

It's an extreme example and won't always be that bad. But it's not uncommon to end up with an OO system like this. And so, to test that getBanana method, I need to instantiate, or mock, an entire forest.

1
  • 1
    This doesn’t answer the question as it has no sample code... – Robbie Dee Apr 4 '18 at 11:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.