Symbol/Semantic leakage. In imperative/OO, I'm organizing as I go using well-established and understood paradigms. In functional programming, you're making thes

Symbol/Semantic leakage. In imperative/OO, I'm organizing as I go using well-established and understood paradigms. In functional programming, you're making these paradigms as you go along, or at least you should be. If you come in with an "I'm going to kick some ass by making these classes to solve my problem" attitude, you're already headed down the OO track whether you realize it or not. Then, sure as night follows day, you or somebody else starts using a functional paradigm, say HoF. There's nothing wrong with any of that. As a professional, you want to be good in multiple paradigms. The problem is that you're mixing them all up, whether you realize it or not (Most of the time, programmers don't realize it) And now, every piece of code can go down two entirely separate tracks as you suss out your architecture. Not only is that not going to work, it's going to make debugging and maintenance a nightmare. This is very, very similar to how good C++ shops work. You've got to tightly limit the way you solve problems in order for all of the programmers involved to be to reason about the code.