If I had to name the single worst thing about Java, it would be the tendency for business code to degenerate into a 1:1:1 ratio of interface:class:public-method.
I agree. It's ugly and hard to maintain. Most enterprise Java usages of "design patterns" are unnecessary cruft. This is where I step back and say, "what you really want is a function".
The argument I tend to make for functional programming is that it only has two design patterns: noun (immutable data) and verb (referentially transparent function). And even though it's very rare that pure functional programming is used, mutable references (e.g. TVars for STM, reference cells like IORefs) are just "noun-plus" and actions (e.g. m a for some monad m) are just "verb-plus". It's easier (read: possible) to reason about the complex stuff if the simple stuff is done on a sound foundation.
Even object-oriented programming is made better by importing functional concepts. Python's take with "classes are simply functions that return objects" is much cleaner conceptually than the "everything is an object and objects do everything" pattern.
I agree. It's ugly and hard to maintain. Most enterprise Java usages of "design patterns" are unnecessary cruft. This is where I step back and say, "what you really want is a function".
The argument I tend to make for functional programming is that it only has two design patterns: noun (immutable data) and verb (referentially transparent function). And even though it's very rare that pure functional programming is used, mutable references (e.g. TVars for STM, reference cells like IORefs) are just "noun-plus" and actions (e.g. m a for some monad m) are just "verb-plus". It's easier (read: possible) to reason about the complex stuff if the simple stuff is done on a sound foundation.