[kartickvad]

You're going too far when you dismiss design patterns as being merely fashion. Just because something is not objectively proven doesn't make it false. Things in the real world are not binary, where they are either objectively proven (hard sciences) or completely false ("The earth is flat"). In reality, lot of things are gray. Design patterns fall in that bucket — many of them help, as long as you remember that there are exceptions.

If many people learnt over and over again that global state, for example, leads to more bugs, you'd be wrong in completely dismissing it just because it isn't objectively proven. Because then you'd be arguing that a program that uses only global variables is just as good as one that's properly encapsulated and abstracted. Do you think anyone would take you seriously if said that?

[learc83]

I don't have a problem with design patterns as a concept. But you need to recognize them for what they are--folk wisdom. Some of it is useful, much of it isn't.

If there is no theory we have to fall back to empirical analysis, and unfortunately our industry hasn't done much of that. The only thing we have to go on is the general "consensus" of the industry, which is cyclical, transient and mostly fashion.

Some of the industry folk wisdom if beneficial and withstands the test of time. Most of us agree that encapsulation is nice. However, we don't agree on what form that encapsulation should take.

OO programmers argue that state should hidden away inside objects, functional programmers believe that state should be explicit and we should always try for pure functions and immutable data when possible. There's very little objective data to support either side (except that functional programming languages tend to have more formal underpinnings). Mostly it falls back to personal preference, which programmer sages you trust, and what the current industry fashion is.

Our industry reinvents the wheel time and again because we are slaves to the cyclical nature of the industry fashion.

Relational Algebra/calculus has been formalized for decades, yet people who don't understand relational theory cried out for something "simpler" and thus NoSQL was born. Fast forward 5 years and you'll find many of the people championing NoSQL had to reinvent most of the tough problems that CS had solved decades ago.

Again, there is nothing inherently wrong with craft and folk wisdom--just like there's nothing wrong with learning salary negotiation, but they don't belong in an academic CS environment. These things are best taught in an internship/apprenticeship after you've learned the underlying theory.