Let me start off with the Object Oriented vs Functional Programming discussion. I do not like this discussion, because it suggests that you have to choose between the two paradigms. In practice most of the things both paradigms do are in my opinion just solid engineering practices. For example, a big part of OO is encapsulation; Does this mean you are not allowed to use this when you are doing functional programming? Or using immutability and monads are big in functional programming, does this mean an OO program cannot benefit from these principles? In the end I personally try to see the underlying engineering principles and try to learn to use the best approach given a certain context. Brian Goetz really words this well in his talk when he ends with (spoiler) "Don’t be an OO programmer, don’t be a FP programmer, be a better programmer"

Another big problem with functional programming is its terminology, and most importantly, how it is explained. Let me start with saying that terminology is important. Calling certain concepts by their correct name helps a lot in both communication and in ways of thinking. By knowing the name you can actually start reasoning about the concept in a different way and start applying it better. So we should not get rid of terminology, but we could do better in explaining it. If you google what a monad is for example, you will probably end up with finding articles about monad laws. For the average programmer, these do not help in actually explaining what a monad is and can even be quite overwhelming. This is because they are now looking at the academical side of FP, and this is a bit of a scary place if you do not have a mathematical background. And because of this some people decide that FP might just not be something for them because it looks like a very complicated way of solving simple problems. People losing interest in (or even worse, hating) FP like this is a shame, since you do not really need to know the mathematical side of FP in order to use its concepts. It is nice that there is mathematical proof, but people do not need that to understand and use for example the Optional. Personally I noticed that people respond a lot better to explaining what the underlying (practical) problem is that we are trying to solve, and stay away from the mathematical side. This way people can start using and benefiting from monads today, and they might get curious about mathematics in the future.

In general I notice that people can get quite dogmatic about certain paradigms. I noticed this with myself as well when I started learning FP and wanted to solve everything using these principles. I even went as far as saying this should be the only way to write software (and in this way participating in the OO vs FP discussion). These days I have become a lot milder in this and try to see the benefits of both paradigms and even different programming languages. I for example do not like Python because of the weak/dynamic typing. It feels a bit dirty to not know if my program will work without running it and finding out (and yes, I know this is slowly getting better). This however does not mean I think Python is a bad language, it is just not the language I would choose for most projects I am working on. If I just want to create a simple program that for example just reads a directory and outputs something Python is amazing. FP languages would make this a lot harder since they force you to think about things like error handling and such, which is a really good thing in general…​ but not if you just want something small to work. And this is not only true for languages, but also for engineering concepts. Having a lot of compile time safety (and reduction in complexity) due to things like monads and immutability is really nice, but it might be a bit much (and even increase complexity) if the problem you are trying to solve was trivial to begin with. For this purpose I personally try to place things on a Scale of complexity. With this I mean that if you are building trivial stuff, you shouldn’t worry that much about complexity reducing principles. If you however are building complicated domain models then the benefits start paying off. And the more complex your application is, the more of these tools you will need to use to manage the complexity. Unfortunately I do not have an actual scale which says from which point you start needing certain concepts, such a thing would be near impossible to create for all contexts out there. But I do think this way of thinking helped me in becoming less dogmatic and therefore come over as more understanding and trying to find the best solution for every problem. So I hope this idea might also help you.

I love Functional Programming, but I do feel we can and should make the concepts more accessible to the average programmer. We can do this by stopping the discussion about OO vs FP and instead of focussing on the underlying engineering principles, do a better job at explaining the underlying problems we are trying to solve and also accept that it is not always the right tool for the job. So I would like to conclude with repeating Brian Goetz; "Don’t be an OO programmer, don’t be a FP programmer, be a better programmer"