The problem arises when you try to couple an OO language with a FP design (or vice versa). You end up leaving large portions of the language on the floor, and

The problem arises when you try to couple an OO language with a FP design (or vice versa). You end up leaving large portions of the language on the floor, and are constantly "inventing" ways to solve problems that you'd get for free if you just did things the way the language was built to do them. The reality is we should be much more flexible with what languages we choose to solve problems, if we want the flexibility to best match our problems to the right design paradigm. Failing that, it's better to go with one "kind" of programming, the one that fits the language. At that point, we're hunting consistency, not the platonic ideal of the solution. Unrelated, but it seems like people here were sold OO as magical or somehow "easy". It's damn hard to get an OO design right, and if it's not working for you, it's probably you and not OO. You probably missed something, which is not only reasonable, but expected. That's where the experience, skill, and expertise come into play.