My first real foray into world of programming was through the use of Java (I had done some Turing but that doesn't count). Therefore I would say my initial teachings of computer science are heavily object oriented with principles in design patterns. I remember first learning of the most well known design patterns (observer, singleton etc...) and thinking to myself what a great a tool I know have at my disposal.
However did I fall into the pit trap of seeing every problem as a nail now that I have found my hammer?
Its corporations and business who want you to think in design patterns, so that they can make money. In functional style a design pattern is simply a higher order function. Everything is much much much more light weight. Design patterns are not extensible and often non composable. One you choose to use one of them you are stuck, for the rest of the life of the application. Design patterns are top-down approach and therefore they "claim" they know the "future" of the application. Since no one can predict how an application will evolve, forget about top-down design and software architects. Software arichtects means incompetence. Use bottom-up and no-patterns.
The above quote I read while looking into ideas for an undo framework for an application I am developing at work. Although I understand/comprehend the point of view I'm not sure I have been swayed. I have not written much in large scale applications but if there is a point where the design pattern used no longer fits the application it would seem that the application itself has evolved into something quite different.
Not sure how far to go into the subject; but rather stick to the point of "Is heavy OOP always the right way to go ?. For now I never mind setting up the overhead that is OOP.
