'Design Patterns' Receives ACM SIGPLAN Award 223
bth writes "ACM's Special Interest Group on Programming Languages (SIGPLAN) recently awarded the 2005 Programming Languages Achievement Award to Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the 'Gang of Four') for their creation of 'Design Patterns' (the computer science book and the subfield at the intersection of programming languages and software engineering). The annual award recognizes an individual (or individuals) who has (have) made a significant and lasting contribution to the field of programming languages."
As mentioned by Paul Graham (Score:3, Interesting)
Re:As mentioned by Paul Graham (Score:3, Insightful)
If I could make a decent living coding in Lisp, I might actually give a shit.
Re:As mentioned by Paul Graham (Score:2)
Yes. Norvig mentions Dylan, too.
Re:As mentioned by Paul Graham (Score:2)
Re:As mentioned by Paul Graham (Score:3, Insightful)
Language bigots always think they're language is perfect. They even seek out its imperfections just so they can figure out how to recast them as perfections instead. Language bigots are among the most prickly people. Even moreso than editor or OS bigots. Prick them and they explode.
Lisp is a great language, but it's not suitable for most mainstream programming tasks. Sorry, but it's not.
Re:As mentioned by Paul Graham (Score:5, Funny)
Yes, language bigots always think THEY ARE language is perfect.
Re:As mentioned by Paul Graham (Score:3, Insightful)
I don't think any real Lisp user will tell you that Lisp is perfect. There is a litany of complaints your average Lisp user has about the language (even Paul Graham). However, most will tell you that its definitely better than what exists in the mainstream. Lisp users are kind of like Linux users in that way, actually. Feature for feature, mainstream languages just
Re:As mentioned by Paul Graham (Score:2)
For a language that's as old and as evangelized and as well liked as lisp, this is very strange.
Re:As mentioned by Paul Graham (Score:2)
Listen to Python or Ruby folks talk about how much more productive they are in those languages versus Java or C++. There is a reason for that. It's because those languages are more like Lisp.
Well, yes, that's sort of true in a roundabout way. Since Perl borrowed a number of things from Lisp. And junior programmers are more productive in Python and Ruby (than Java or C++) because those languages are like Perl with training wheels.
<rd&g>
Re:As mentioned by Paul Graham (Score:3, Informative)
What i
Re:As mentioned by Paul Graham (Score:2)
Beyond that, as Graham points out, there are few patterns in well-written Lisp code. If a Lisp programmer finds himself repeating the same pattern of code over and over, he'll just write a macro to codify the pattern. It should be not
Re:As mentioned by Paul Graham (Score:2)
First, duplicated code != a design pattern.
Second, what can a Lisp macro do that, say, a C macro or a function can't? (I ask merely for information, I'm not challenging you.)
Re:As mentioned by Paul Graham (Score:2)
Re:As mentioned by Paul Graham (Score:2)
A Lisp macro performs an arbitrary rewrite of a Lisp expression into another Lisp expression. Because Lisp programs are expressed as Lisp data (i.e., lists), and because the full power of Lisp is available to implement this transformation, it is much more powerful than a C macro.
The upshot of this is that macros can be used to extend the control structure of Lisp itself. (Think templates on
Re:As mentioned by Paul Graham (Score:5, Informative)
Lisp macros and C macros share only a name. The C preprocessor is just a simple text-substitution mechanism. In comparison, Lisp macros are functions that take source code as input, and return source code as output. They have all the generality of regular functions, except the compiler invokes them at compile-time to expand calls.
The simplest examples of Lisp macros are defining new control structures. For example, Lisp has no direct equivalent of Python's "for elt in container" syntax. However, it's easy to write a macro that takes the statement (for (x in list)
With regards to macros and patterns, an easy way to think about things is to realize that functions are useful when you need to apply the same code to different data, while macros are useful when you need to apply the same structure to different code. The classical idea is that you can't package up design patterns into a library. That's because few languages have macros (ie: functions that operate on source code). When you have such a feature, packaging up design patterns becomes easy. Just codify the invariant parts into the macro, and put the parts of the code that change as parameters to the macro. If you've read Alexanderescu's book "Modern C++ Design", you'll see that this is precisely what he does with C++ templates (which are a limited and kludgy form of macros). This is big news in the C++ world, for the simple reason that it makes code less tedious to write and less error prone.
Re:As mentioned by Paul Graham (Score:2)
My guess is that you meant "a feature of the Java and C++ class systems".
I can, off the top of my head, think of three things that you can do with C++ that you can't do with CLOS, or even CL (except through external libraries):
(Yes, the cdr of a cons is (usually) a kind of pointer, but it can't point to an
Short reply (Score:2)
He isn't.
Re:As mentioned by Paul Graham (Score:3, Informative)
Re:As mentioned by Paul Graham (Score:2)
Re:let me second that (Score:2)
It doesn't seem like much on the surface, but he strikes at the heart of statements like yours. No matter wat you do to your language, you cannot systematically replace discipline with procedure. In this case, you are basically blaming the language for the need to learn design patterns. But really, no language will free you from having to learn how to program in the correct way.
Another mentor of mine told me that design patterns in
Re:let me second that (Score:2)
Software development was governed by design patterns long before the GoF wrote their book. What is depressing is that (1) people like you think these people actually invented patterns, (2) you didn't figure it out for yourself before picking up the book, (3) most of the actual patterns in that book are workarounds for limitations of current OOLs, and (4) people like you think that all of that is really just fine. It's the blind (GoF
Re:let me second that (Score:2)
Awesome plan. While we're at it, let's get rid of all the books too. Documentation is a crutch as well, so let's delete all that. And burn down the universities - no-one ever gained anything from them that they couldn't have figured out in their own lifetime.
Also, no-one should be allowed to pass on advice, because everyone should be able to work this shit out for themselves.
Re:As mentioned by Paul Graham (Score:2)
terminology, methods, what? (Score:5, Insightful)
Or is it more about just giving programmers a common vocabulary with which to discuss the way they bulid software?
Is it good reading for an amatuer programmer, or more as an advanced topic?
Re:terminology, methods, what? (Score:5, Informative)
It gives standard terminology for talking about, among other things, how you'd implement an undo function in an application.
However, such standardization flies in the face of the need to re-invent the wheel and sell it as a shiny new technology.
Re:terminology, methods, what? (Score:3, Informative)
For anyone doing object-oriented programming, this should be required reading IMHO. It gives you a solid base on how to solve most moderately complex problems.
Re:terminology, methods, what? (Score:3, Insightful)
When we moved to OOP, new idioms were needed. W
Re:terminology, methods, what? (Score:2)
Re:terminology, methods, what? (Score:2)
Also important is that it lets you know of the "consequences" of using a given pattern, both good and bad. If you employ the composite pattern, for example, you treat a group of objects the same as a single object, and the container will recurse through the children.
The other th
Re:terminology, methods, what? (Score:2)
It's easy to talk about control structures like for loops, functions, etc because they have names. It's easy to say things like "it's insane to have all that code in one function".
Software architecture, which is a level more abstract than syntax and control structures, lacked such names for some time. Instead of names, you'd describe a solution or something.
If you haven't named something, you can't talk about it effectively. You can't discuss its pros and cons with people easily. And so on.
"Des
Re:terminology, methods, what? (Score:2)
Design patterns are recurring algorithms in software design. Take the "Singleton" pattern, which is usually regarded as the simplest. You use a private class variable, and a public getter (and either a setter or lazy initialize on the first get). What you're trying to do is make sure there's one and only one instance of a variable on the
A little from column A, a little from B (Score:2)
I generally find that I prefer to let my code dictate my patterns, rather than the other way around. When building a system which calls for a centralized menu (or command line) to invoke various procedures, it's generally
Well deserved (Score:4, Informative)
For OO fans... (Score:4, Informative)
Oh dear... (Score:3, Insightful)
The quite possibly most useless book in the history of computer science gets an award. Somehow I am not that surprised, considering that everybody hails it as the end all of object oriented design and everything.
To be honest, modern computer science curriculum seems to be wasting a lot of bright young potential on buzzwords. Patterns, paradigms, bleh. People somehow manage to get masters degrees in CS from Berkeley without even knowing what "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis" are. But you ask them about a singleton, model-view controller or Java's security model in reflection and they're the fucking expert.
Well that's barely computer science, that's just OO banging. Just because it uses paradigms and object oriented terms doesn't make it anything other than advanced code banging.
Re:Oh dear... (Score:2)
Check out that first comment: 16 of the 23 patterns are so simple as to be invisible when you use the right tools.
Re:Oh dear... (Score:5, Insightful)
I find it useful with what I work on. If you don't then, maybe the book just isn't for your line of work.
Design patterns are a tool, not a silver bullet. Get what you can out of them but don't be surprised when doesn't solve all the problems in the world.
Re:Oh dear... (Score:2)
OO langues provide some facilities that make implementation easier, but every language can have design patterns. All a design pattern is, is a solution to a common design problem. The only way a language would not have any design patterns is if it allowed you completely skip the design phase.
Re:Oh dear... (Score:3, Insightful)
Re:Oh dear... (Score:2)
Re:Oh dear... (Score:3, Insightful)
Interesting - tha
Re:Oh dear... (Score:2, Insightful)
Interesting - that
Re:Oh dear... (Score:3, Interesting)
Re:Oh dear... (Score:4, Insightful)
But, you know, in case that trucking company struggling with logistics needs to know about "turing complete", "Karnaugh map", "Rice's theorem", "Goedel's completeness theorem", "planar graph", "functional language", "church-turing thesis", they're golden.
Re:Oh dear... (Score:2)
Yep. By a remarkable coincidence, I actually happen to have a summer job working at (guess what!) a trucking company stru
Re:Oh dear... (Score:2)
Re:Oh dear... (Score:4, Insightful)
Therefore, sure, Computer Science is science, but understand that its pure semantics. Its good that enrollment in CS is down, because most of the CS students during the boom were more interested in engineering (applying known scientific discoveries) than the science itself.
The fact that employers looking for programmers ask for CS degrees is simply an indication that the industry is still fairly young. Software engineers used to come out of CS, but that trend is rightfully dwindling. Most programmers really should be trained in an engineering course, where the focus on economics and social responsibility are more pronounced.
Re:Oh dear... (Score:4, Insightful)
You're obviously trying to come off as pompus but seriously, do you even really know what you're talking about? What's so important about Karnaugh maps? It's a silly way as solving a system of boolean alegbra equations. Only really useful for introduction digital circuit design.
If you want to talk about boolean logic, talk about predicate calculus, modus ponus, or something that actually deals with Computer Science theory.
I understand where you're coming from and don't fully disagree but you sound like an ass. There's always someone with a more theoritical background than you so just don't do that.
FWIW, the GoF are important because they were the *first* to do what they did--give programmers a common vocabularily to describe complex systems.
Re:Oh dear... (Score:2)
Creating a Software Engineering program in the engineering school is a better idea; it and a CS program could complement each other nicely. SE undergrads need some basic amount of theory, which they could get from the CS program, and CS undergrads need some basic amount of SE knowledge, which the SE program could provide. The o
An Excellent Book (Score:3, Informative)
Re:An Excellent Book-Plus one (Score:2)
Experience for the unexperienced (Score:2, Funny)
Re:Experience for the unexperienced (Score:2)
Excellent material, often taught incorrectly (Score:5, Interesting)
Congratulations to the GoF. Their observations of patterns of systems and behavior are well-described and well-cataloged in their book. I only wish the concepts and materials were conveyed better when taught.
Most of the time people start with the attitude "Let's start with the Visitor pattern" or something like that. The point of the patterns movement is there are common things that are done, wouldn't it be nice if we could talk about them with common terminology and use the full richness of our experience to ensure when we see the problem again that we don't make all the same mistakes we made last time.
I'd like to see it taught (and this can be in the programming shop, too) like this: "What are we trying to do? Where have we done something like this before? Doesn't this look like something we've done last month? Can you detect a pattern to all this?!"
Instead, what I often see if people spouting pattern names like one would name-drop at a party--the more you drop the more important you must be. Starting with the problem to be solved, the understanding of same, and then recognizing that we've seen this before, then naming the pattern is less flashy but is more the intent of the GoF IMHO.
Re:Excellent material, often taught incorrectly (Score:3, Interesting)
I'm seeing this at work, and it's driving me nuts. Our new Bible is "Architectural Design Patterns". The big push right now is to move to
Re:Excellent material, often taught incorrectly (Score:2)
Re:Excellent material, often taught incorrectly (Score:2)
For example, the persistence framework we use actually generates proxy classes on the fly that handle transaction management, etc. Hooking into these things (and determining how to build them) requires some advanced reflective techniques.
I'll put a cheap plug here, since it's awesome: www.x-te
Re:Excellent material, often taught incorrectly (Score:3)
My coworkers aren't stupid, they've just getting a lot of positive feedback from their use of buzzwords.
Re:Excellent material, often taught incorrectly (Score:2)
There's also a unit test framework for C++ called CppUnit, which was intended to bring the benefit of more formal unit testing to that language. However, since C++ doesn't support reflection, you end up having to employ macros to use it. It's not self-discovering.
Otherwise, I haven't noticed its absence
worth it for one reason (Score:5, Informative)
groundbreaking, IMO; the genius of the book
is the perspective on looking at software
as pattern definitions and then their use
in different ways and places in software.
The part that every OO developer should
ingrain in their brain is to
Prefer composition to inheritance.
Good Lord, people love their inheritance
when there are very, very rare situations
that call for it. (Composition, btw, is
where a data structure is used as a data
member of the class).
What it recommends is that instead of this:
class cElement : cParent {
use this:
class cElement {
cParent mParent;
}
Inheritance is so friggin abused by OO
developers, it is ridiculous.
So, my recommendation is to read the first
50 pages or so, which is their general
perspective on programming. After that,
it's just details about the patterns they
have encountered in their careers.
Peace & Blessings,
bmac
Re:worth it for one reason (Score:3, Insightful)
Using composition for everything is just as bad as using inheritance for everything. That inheritance seems to be your pet peeve, makes me think that you use composition much more than you should. Everything has its balance, but when you go out on a limb to tell someone else that he's unbalanced, make sure that limb doesn't break.
Re:worth it for one reason (Score:2)
Re:worth it for one reason (Score:2, Insightful)
A circle "is a" elipse. Should a circle class extend an elipse class, even though a circle doesn't behave as an elipse (e.g., one cannot independently alter both axis and still have a circle). Nope. "is a" is not what matters. "behaves as a" is what matters.
Re:worth it for one reason (Score:2)
Re:worth it for one reason (Score:2)
Inheritance and composition are different tools, and are used for different purposes. Sur
Re:worth it for one reason (Score:3, Informative)
I just saw a presentation where the guy gave an example of a CSquare inheriting from a CRectangle. He said look at the differences: if your CRectangle has a SetSize(int height, int width) method, what do you do if the width isn't the same as the height? Perhaps you should have a SetSize(int side) method instead. But then it's still different enough that the two really aren't as related as they seem, even though a square is most certainly a rectangle.
I agree th
Re:worth it for one reason (Score:2)
Re:worth it for one reason (Score:2)
Sure they should be separate classes. Consider:
CFourSidedPolygon rectangle(100, 50); // okay, it makes sense to widen rectangles
rectangle.setSize(200, 50);
// now make a square 50 units wide and 50 units high
CFourSidedPolygon square(50, 50); // okay
// whoops, our "square" is no longer a square!
square.setSize(100, 50);
The point is
Re:worth it for one reason (Score:2)
Inheritance is never necessary. But just saying "always use object composition" doesn't make sense either, in and of itself.
All objects should be considered as an assembly with a boundary, with multiple terminals to connect to other components. Each terminal can have its own interface type. Multiple interfaces nodes (connectable terminals) with different types is a m
Re:worth it for one reason (Score:2)
Re:worth it for one reason (Score:2)
No, keep reading!. The patterns are useful, and may give you insight into a better way for solving certain common problems. But far more importantly, it gives you a common language to use with fellow software engineers. I find that in the corporation I work for, more and more people are familiar with these p
Re:worth it for one reason (Score:2)
inheritance at all costs, but rather to
only use it where needed. And in my
many years of programming, polymorphism
has rarely been needed. Off the top of
my head, the only time I've needed it
was when implementing a simple window
manager where each different control
needed to implement the standard control
fcts onKey and onMouse or somesuch.
Personally, I'd say that I prefer to
use an enum for the obj's type and then
use a switch to handle the different
cases within the member
Re:worth it for one reason (Score:2)
Re:worth it for one reason (Score:2)
use an enum for the obj's type and then
use a switch to handle the different
cases within the member functions.
Our browsers
handle line
breaks just
fine thank
you.
Anyway, congratulations on reinventing polymorphism. Of course by keeping all the code in one place, you no longer keep the behavior of a particular object in one place. Changed from a linked list to a hashtable? Better update 20 functions in 20 files.
I know it's considered bad-practice, but
it does keep all the co
An observation... (Score:5, Insightful)
- This mantra is good for money, horsepower, disk space, but not design patterns...
When somebody starts telling me that they used 5 different patterns in their program and they're proud of it - then I know the code is crap. Most of the pattern zealots I've seen write bloated, inefficient code. Sometimes I think they scour the literature looking for some extra patterns to put in.
That said, these patterns do exist and programmers keep reinventing them. The key is knowing when to call it a pattern and go to the trouble of formalizing it versus just writing code. Alternatively, find a language that makes most of these go away.
Re:An observation... (Score:2)
Re:An observation... (Score:2)
Re:An observation... (Score:2)
Well, that's as may be, but log4j has been my company's official logging framework for the last couple of years, and in that time all we've ever had to do with it is:
1) create a static instance of a Logger in each class that needs to log stuff
2) call the appropriate logging method to output log lines (eg logger.debug(), logger.info(), etc
Re:An observation... (Score:2)
As a Patterns zealot, a book I'd recommend to most Pattern fanatics, as well as to any Pattern skeptic, is "Refactoring to Patterns", by Joshua Kerievsky.
It's a pretty good book on moving towards and (gasp!) away from design patterns ba
Re:An observation... (Score:2, Insightful)
And do this for every class in your system!
Design patterns are a great idea but they can lead to a huge increase in complexity when peo
Re:An observation... (Score:2)
As with all things, you can take pattern usage too far. Doing so is not unique to patterns, and as in other situations, is the mark of a bad programmer. Bad programmers are going to be bad whatever tools you give them.
Re:An observation... (Score:2)
Easily mastering design patterns (Score:5, Informative)
I'm reading Head First Design Patterns [amazon.co.uk], published by O'Reilly, right now. It's an fun and easy to read Design Patterns course, which is difficult to put down once you started it. The authors have a great sense of humour, and use a very practice-oriented approach. They tackle day-to-day problems by starting with the obvious solution an inexperienced programmer would use. Then they point out the problems with this solution, and step by step they work to the appropriate design pattern. Patterns are examined from different viewpoints, and the authors try to answer all the questions you might have.
I really recommend this book. In fact, I recommend the whole "Head First" series (I also own Head First EJB). These books are not usable as reference works, but they are wonderful for learning and mastering a subject.
Re:Easily mastering design patterns (Score:2)
Re:Easily mastering design patterns (Score:2)
The problem with patterns (Score:5, Interesting)
Re:The problem with patterns (Score:2)
In a resource constrained sitution, sometimes you are forced to re-build the wheel. However, design patterns help people prevent having to re-invent it.
The question is; do I have to figure out *how* to build it myself, or are there recipies available out there already?
I appreciate those who work towards building smarter and better tools, but many of us
Re:The problem with patterns (Score:3, Insightful)
Re:The problem with patterns (Score:3, Insightful)
Alexandrescu's pre
Christopher Alexander: The true originator? (Score:2, Informative)
I'm fairly confident the concept of design patterns truly originated with these two books. The concept from architecture was then applied to software.
The fundamental idea being that there are certain components of architecture that "just work" and "feel right". They may solve very complex problems in elegant a
Re:Christopher Alexander: The true originator? (Score:2)
However, in my view - and at least a few others - the pattern concept as understood by software people is generally neutered. alexander focuses on the process; patterns are nearly worthless without the generative way in which one employs a patt
Re:Christopher Alexander: The true originator? (Score:2)
Give it to Code Complete, instead... (Score:3, Interesting)
I know that in the OO languages world, this book is hailed by many as the holy book, but to me, there really is only one... "Code Complete".
The one book teaches the fundamentals of good programming *in any language* better than any programming book ever written.
Case in point, I don't think any shit code has been written as a result of applying the techniques and best practices in "Code Complete". I certainly can't say the same about "Design Patterns".
We need more books on the same subject (Score:2)
Granted, I read it recovering from surgery with anesthesia in my system, but I found it to be prohibitively dense material for concepts that don't warrant that density.
The contribution to programming from those concepts will be fully realized when they are expressed in a form easily digestible by busy programmers who have to do a lot in the real world.
Design patterns - the emporers latest new clothes (Score:2)
IMO its time to ditch all this high level buzzword trash coding methodology and go
Re:Design Patterns are Band Aids for OO programmin (Score:2)
What do you mean Lisp doesn't have object oriented features? Have you heard of CLOS, built into Common Lisp? (CLOS is even older than C++, CLOS was the first OO extention of a mainstream language.)
Even Paul Graham, a Lisper critic of
Re:Design Patterns are Band Aids for OO programmin (Score:2)
Everyone: Please ignore this book, and actually solve the problems you have; rather than attempting to look up the answer in this "solutions manual" for writing programs.
--Ender
Re:Design Patterns are Band Aids for OO programmin (Score:2)
But this is exactly the point. High-level abstractions are fantastic, but there will always be a need for, if nothing else, alternate implementations of those abstractions. As long as we still need a language sitting where C++ sits relative to the hardware, we'll need these elegant solutions to the "braindead limitations" of lower-level languages.
Re:Boring book apart from first 50 pages (Score:2)
Quite. And why do we still have wheels on vehicles 10,000 years after the wheel was invented? Surely someone could have come up with something better by now!
Agree with you about patterns tho.
Re:Do nearly all programmers just do User Interfac (Score:2)
I find patterns most useful in three specific areas: container/list class design, database design and database to class mapping.
I wro