1

What is the fascination with taking old concepts coming up with a buzzword for them and pitching it as new technology complete with 800 page tome with nerd on the cover?

A long long time ago, lets say the 80's, I wrote software. It was designed reasonably well and it worked and was maintainable. It separated out different high level functions into different libraries of code and so on.

Sometime in the past 10 years, I lose track of the exact time, "Patterns" became popular. Whole encyclopedias were written about design patterns and this patterns and that patterns.

We've been doing it for decades (and I'm sure long before I started programming) yet it is suddenly new and novel.

Is this just a gimmick to sell books and educational classes? Why add so much noise to the already overcomplicated world of programming when getting things done well is really what matters.

gnat
  • 21,442
  • 29
  • 112
  • 288
stu
  • 161
  • 4
  • Hi stu, this reads like a thinly-veiled rant: if there's something specific about a problem you're actually facing in software development you need someone to help solve, feel free to ask about that instead. –  Oct 24 '11 at 21:45
  • Related: http://programmers.stackexchange.com/questions/70877/are-design-patterns-really-essential-nowadays/70893#70893 – pdr Oct 24 '11 at 23:30
  • yes, that's what I was trying to get at. – stu Oct 25 '11 at 16:29

2 Answers2

12

Well, when the GoF wrote the book on Design Patterns, they intended to essentially document existing best practices so people didn't have to reinvent the wheel. So your criticism that these are old ideas is actually the whole point.

jiggy
  • 1,590
  • 11
  • 15
  • 2
    Giving names to things so people can talk about it and make code clearer (if it says "Decorator" it is clear, without reading al ine of code what it should do - while osmetimes it doesn't so you should stil lread the code ;-) ). – johannes Oct 24 '11 at 21:16
1

Jiggy's got a good point. In addition, there is the concept of a "paradigm"; an established way of thinking about how to solve problems. Different paradigms have different best practices. When new paradigms come around, best practices change to take advantage. Notable shifts in thinking include object-oriented vs procedural coding, event-driven programming (where the OS controls the program instead of the other way around), multithreading (computers are approaching the limit of how fast they can do one thing at a time; so, make them able to do several things at the same time), etc etc.

When things change, old patterns and practices become obsolete. If you're learning how to structure code using a C book from the 80s, you will be run out of town trying the same thing in C++. If you know C++, you will have a leg up learning Java, but there is still a world of difference, primarily in memory management (you always destroy your own objects in C++; in Java, you almost NEVER destroy your own objects). Even between Java and C#, two object-oriented memory-managed languages, there are very different ways of thinking about structuring objects in those languages (implementing the "singleton" pattern, for instance, is different based on the semantics of each language). Knowing these semantic differences, and yet still being able to tie them back to basic object-oriented concepts, as languages grow and expand their capabilities, is what keeps authors and publishers in business writing programming books.

KeithS
  • 21,994
  • 6
  • 52
  • 79