Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

'Design Patterns' Receives ACM SIGPLAN Award

timothy posted more than 9 years ago | from the good-idea-guys dept.

Software 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."

cancel ×

223 comments

Sorry! There are no comments related to the filter you selected.

ARexx (1)

FosterKanig (645454) | more than 9 years ago | (#13205062)

Unless it uses ARexx, it's not real programming!

As mentioned by Paul Graham (3, Interesting)

putko (753330) | more than 9 years ago | (#13205067)

As mentioned by Paul Graham [paulgraham.com] , in his essay "Revenge of the Nerds", Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp. [norvig.com]

Re:As mentioned by Paul Graham (0)

Linus Torvaalds (876626) | more than 9 years ago | (#13205079)

Er, wouldn't that be "as discovered by Peter Norvig"? Why are you giving the credit to Paul Graham?

Now that you have commented on it, I could be technically correct in saying "as mentioned by putko", but the emphasis would be all wrong, wouldn't it?

Short reply (1)

rbarreira (836272) | more than 9 years ago | (#13205106)

Why are you giving the credit to Paul Graham?

He isn't.

Re:As mentioned by Paul Graham (0)

Anonymous Coward | more than 9 years ago | (#13205087)

In fairness, Lisp has some difficulty with more complex patterns, such as Loop.

Re:As mentioned by Paul Graham (2, Informative)

be-fan (61476) | more than 9 years ago | (#13205427)

The loop macro itself is an acquired taste, but Lisp doesn't have any particular problem with it. C++ programmers try to find a "for loop" in Lisp, but there isn't really an equivalent. There is a 'for' macro of course, but it's not like in C++ where its used for all iteration, even when it doesn't really make sense. Instead, Lisp programmers use a range of iteration techniques that fit the bill. They use map, mapcar, for, dolist, etc, whichever makes sense in the given spot. In Lisp, there is almost always an iteration construct that expresses exactly the iteration you want to do, without you having to try and figure out how to express your iteration in terms of 'for'. Of course, if there isn't, you can always use loop, or write a macro to roll your own.

Re:As mentioned by Paul Graham (1)

rsheridan6 (600425) | more than 9 years ago | (#13205984)

There is no "for" macro in Lisp, though there is a "for" keyword in the loop macro. There's nothing stopping you from defining one yourself, of course.

Re:As mentioned by Paul Graham (3, Insightful)

whatthef*ck (215929) | more than 9 years ago | (#13205142)

As mentioned by Paul Graham, in his essay "Revenge of the Nerds", Peter Norvig found that 16 of the 23 patterns in Design Patterns were "invisible or simpler" in Lisp.

If I could make a decent living coding in Lisp, I might actually give a shit.

Re:As mentioned by Paul Graham (0)

Anonymous Coward | more than 9 years ago | (#13205291)

So, rather than bemoan the fact that there aren't as many Lisp jobs as C#/.NET jobs, why not try to integrate Lisp into your current job whenever possible? Assuming of course you're actually interested in expanding your skills.

Re:As mentioned by Paul Graham (1)

whatthef*ck (215929) | more than 9 years ago | (#13205417)

So, rather than bemoan the fact that there aren't as many Lisp jobs as C#/.NET jobs, why not try to integrate Lisp into your current job whenever possible?

What for? What would Lisp give me that I can't get from Java, Perl, C, C++ or bash, that would be worth the effort it would take to learn a language there's virtually no market for?

Assuming of course you're actually interested in expanding your skills.

Only to the extent that there's some practical use for the skills I'd be acquiring. And I don't count among practical uses the ability to pretentiously extol the virtues of near-dead niche languages, the way tools like Paul Graham do.

Re:As mentioned by Paul Graham (0)

Anonymous Coward | more than 9 years ago | (#13205551)

Speaking from personal experience I can do things in Comman Lisp faster than in any of those languages, but perhaps this http://www.gigamonkeys.com/book/ [gigamonkeys.com] gives more practical examples than that.

Re:As mentioned by Paul Graham (0)

Anonymous Coward | more than 9 years ago | (#13205598)

That would be Common Lisp.

Re:As mentioned by Paul Graham (0)

Anonymous Coward | more than 9 years ago | (#13205717)

What for? What would Lisp give me that I can't get from Java, Perl, C, C++ or bash

In the sense that they are all Turing complete languages, nothing; that's the wrong question to ask when comparing any programming language. The real difference is how readily you can express certain ideas and whether the low-level details help you or get in your way. And trying it for yourself is the only way to evaluate it for whatever purposes you have in mind.

Lisp advocates like Lisp for a variety of reasons, it's not just smoke & mirrors. But if you never try it, you'll never know either way. And even if Lisp does turn out to be totally useless for whatever reason, stretching your mind by learning a slightly different language (you didn't list any functional languages) will make you a better programmer.

As mentioned by Deep Throat. (0)

Anonymous Coward | more than 9 years ago | (#13205373)

"If I could make a decent living coding in Lisp, I might actually give a shit."

If I could make a living fucking women, I might actually give a shit.

Those who can, do. Those who can't buy the videos.

Re:As mentioned by Paul Graham (0)

Anonymous Coward | more than 9 years ago | (#13205383)

I would make a guess that this doesn't just hold for Lisp but any decent dynamically typed programming language.

Re:As mentioned by Paul Graham (1)

EvanED (569694) | more than 9 years ago | (#13205283)

I must admit that I have never programmed in Lisp (my functional languages experience is limited to ML), but I would bet a substantial sum that there are at least a few idioms in Lisp that could be considered analogous to the OO design patterns that an OO language makes invisible.

Re:As mentioned by Paul Graham (2, Insightful)

Brandybuck (704397) | more than 9 years ago | (#13205374)

Of course :-)

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 (4, Funny)

shmlco (594907) | more than 9 years ago | (#13205472)

I just can't help myself given that sentence. To quote, "Language bigots always think they're language is perfect."

Yes, language bigots always think THEY ARE language is perfect.

Re:As mentioned by Paul Graham (2, Insightful)

be-fan (61476) | more than 9 years ago | (#13205478)

What's your reasoning behind the assertion that Lisp isn't suitable for most "mainstream programming tasks". Just saying it doesn't make it true.

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 can't compete with Lisp. And it's not just a Lisp thing. 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. [paulgraham.com]

Re:As mentioned by Paul Graham (1)

teknomage1 (854522) | more than 9 years ago | (#13205723)

I'm bsting my ass to learn lisp based it's ability to map to my problem domain, but it's damn hard to fnd documentation on how to interface with the rest of my system facilities for the free lisps. That's a barrier to entry at least that may be impractical for many. Also all this research (on socket programming in this case) Is really killing the productivity gains the rest of the language provides. As a college student this isn't a deal sealer for me, but if I were on the clock...

Re:As mentioned by Paul Graham (2, Informative)

be-fan (61476) | more than 9 years ago | (#13205908)

Your point is well taken, but note that your problem is basically a combination of lacking documentation and you still learning the language. The first is the fault of the language (well, the implementation, but still), while the latter is nobody's fault, because it's an inevitable situation. I would assume that if you were on the clock, you would already know the language you were working in. Ie. if the project were in C++, you'd already know C++, or else you wouldn't have gotten hired to work on it.

What implementation are you on, anyway? Depending on what kind of networking you need, the trivial-sockets [cliki.net] library could be up your ally. Very simple way to connect Lisp to a network. If you're on SBCL, there is SB-BSD-SOCKETS [sbcl.org] , which exports an API pretty similar to standard UNIX sockets. Of course, for the best in documentation quality, springing for a copy of Allegro CL will get you the ACL socket API [franz.com] . Since you're a student, you can get a copy for a mere $99, or about what you'd pay for an academic version of any other commercial software.

Re:As mentioned by Paul Graham (0)

Anonymous Coward | more than 9 years ago | (#13205566)

Language bigots may be bad (I've probably succumbed to being one at times), but I find anti-language bigots an even more interesting phenomenon.

(I am _not_ referring to you here, by the way.)

There are people who have never used Lisp, and yet think that it's bad, and ask Lisp users why they would use such a thing. LIke it's a waste of time. Now, I don't mind if someone has tried Lisp and doesn't like it. But it can be annoying to hear folks complain about Lisp when they really don't know anything about it.

That said, I have probably overdone my endorsement of Lisp at times. It's not the best language in every situation. It's a great language, but when you take into account the need for modern libraries and source code readability, Lisp doesn't always win. (Of course, overendorsement from a few people in the face of anti-Lisp folks might all even out in the end...)

Python, for example, can probably handle 80% of what Lisp is used for (a rough estimate). 80% of the time, Python would be fine. It's only on those 20% of the projects where you really need extra linguistic power that the pluses of Lisp (macros, lambdas, etc.) overcome the minuses.

Those projects do exist, but they are more rare than projects for which Python would be fine. And even then, some sort of Python front-end, Lisp back-end system might be in order, letting Python handle the string processing, database queries, and such.

Re:As mentioned by Paul Graham (1)

be-fan (61476) | more than 9 years ago | (#13205452)

Not really. I haven't encountered a feature of Java or C++ that is not directly expressible in CLOS. This includes fancy new Java 1.5 and C# 2.0 stuff like properties, etc. Now, once you get out into real OO languages, like Smalltalk, you might find something, but its doubtful.

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 noted that CLOS itself is mostly just a big macro package. Now, compilers generally have some knowledge of CLOS these days, for optimization purposes, but they don't really need to.

Re:As mentioned by Paul Graham (1)

EvanED (569694) | more than 9 years ago | (#13205543)

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.

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 (1)

swimmar132 (302744) | more than 9 years ago | (#13205602)

A Lisp macro is absolutely nothing like a C macro. They do completely different things, so you can't compare them.

Re:As mentioned by Paul Graham (1)

jjhlk (678725) | more than 9 years ago | (#13205642)

I think Lisp macros can do things with the AST, wheras C macros manipulate text. That is, one is about as powerful as a compiler, and the other is about as powerful as a preprocessor.

But, I'm a programming amateur and use neither C nor Lisp.

Re:As mentioned by Paul Graham (1)

sv0f (197289) | more than 9 years ago | (#13205647)

A Lisp macro is a function that is applied at compile time, not run time, so in this sense it is not like a C function.

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 steroids, perhaps.) This allows you to (more) neatly encapsulate what would be a complex idiom or design pattern in languages that lack similarly powerful macro facilities.

(Scheme, the bastard offspring of Lisp and Algol, has a "hygenic" macro facility that has a number of interesting properties. Dylan, a Lisp with more conventional syntax, also has an interesting macro system. I am unaware of any other comparable languages in this regard.)

I hope this helps.

Re:As mentioned by Paul Graham (4, Informative)

be-fan (61476) | more than 9 years ago | (#13205870)

You're right, design patterns aren't duplicated code. They're duplicated patterns of code. Nearly all languages have a tool for handling duplicated code (functions), but few have tools to handle duplicated patterns of code. Lisp macros, however, do allow you to codify patterns in code.

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) ...)" and expands it to an iteration using Lisp's native 'do' loop. Now, that's just scratching the surface of macros. Since macros are just functions, you can do anything with them, including writing a language on top of Lisp. This might seem like a bit of a strange idea, but domain-specific languages are hardly a new concept (ie: SQL), and its easier to build them on top of a mature platform instead of writing your own compiler.

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.

let me second that (0)

cahiha (873942) | more than 9 years ago | (#13205917)

Design patterns are largely cookbook workaround for poorly designed languages and libraries. It's pretty depressing that this is the best that software engineering and programming languages have to offer in 2005.

hola (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13205070)

coom estan todos. FP.

terminology, methods, what? (5, Insightful)

Rubel (121009) | more than 9 years ago | (#13205076)

I've worked with a couple of folks who swore by this book, but I never really heard much from them about why. Is it about good algorithms? Or larger design issues (such as)?

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? (4, Informative)

smitty_one_each (243267) | more than 9 years ago | (#13205114)

It serves as a common language for designers to talk about what they're doing.
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? (2, Informative)

IntergalacticWalrus (720648) | more than 9 years ago | (#13205141)

It's all about "design patterns", ie. the sorting and naming of common design problems a programmer has to face in object-oriented programming, and how to solve them right, so the code remains as maintainable and cohesive as possible.

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? (0)

Anonymous Coward | more than 9 years ago | (#13205360)

1) invent complex terminology for design strategies which have been used almost as long as programming languages have existed
2) Write books and give high priced software engineering lectures
3) Profit!!!

Re:terminology, methods, what? (3, Insightful)

fermion (181285) | more than 9 years ago | (#13205527)

I think it is about idioms. There are standard ways to copy, iterate, and count. These standard not only make the code more readable, but also provides time tested methods to make the code reliable. Also using these idioms when writing code speeds up the process. There was a time when I could at sketch out a solution to a moderately complex problem in a day, flesh it out in another day or two, and then spend the rest of the time debugging and clarifying.

When we moved to OOP, new idioms were needed. We kept many of the old ones, and the OOP made complying with some rules, such as the separation of data, presentations, and manipulation, simpler. This is what design patterns does. It provides a set of idioms that can be applied to classes of problems. Once these are learned, one should be able to quickly develop a robust solution.

Take for example the singlet. It is a simple construct used when only one instance of an object is allowed. This happens more than one might imagine. I could sit down and think hard for a while and implement singlet, and then redesign, and debug, and after months of work come up with a good solution. Or I could just use the design pattern and in 20 minutes implement my singlet class.

The second part of you question is more complex. I, like most programmer, created crude versions of the design patterns on my own before reading this book. I even saw I enforced some OO concepts on my structured programming. Once I read the book I quickly saw the uefulness and began to use the patterns in my professional work. OTOH, when I was coding some math stuff over the summer, I did not use the patterns because the work was not so suited to the patterns. If i were to publish the work, I might go back and rework to fit the idiom. OTOH I know that the book is used widely and knowing the basics are useful. So if you are coding for fun, it might not help that much. If you are coding to show others, it would help to put the code in a form people will recognize.

Re:terminology, methods, what? (1)

DrEasy (559739) | more than 9 years ago | (#13205606)

It simply opened my eyes about what true OO was about. I thought I was already fairly proficient in Smalltalk, but it's after learning a few of the patterns in the book that I truly understood the need for abstract classes and methods, the proper use of inheritance (vs composition), and the constant fight against code duplication.

Re:terminology, methods, what? (1)

Profane MuthaFucka (574406) | more than 9 years ago | (#13205973)

It's a cookbook!

(now watch someone who hasn't read the damn thing mod me down. Then, watch everyone laugh at that someone.)

Well deserved (3, Informative)

Sv-Manowar (772313) | more than 9 years ago | (#13205085)

Its good to see these people being recognized for contributing such a useful concept to object oriented programmers, and its wholly appropriate they should recieve such an award from a group focused on exploring "implementation and efficient use" of programming languages. Although they have their critics, Design patterns have surely helped many programmers greatly in this manner, especially in languages such as java.

They deserve it (0, Redundant)

IntergalacticWalrus (720648) | more than 9 years ago | (#13205124)

In my software engineering studies, virtually all of my teachers swear by the design patterns of the Gang of Four book for all object-oriented programming projects.

design methodology du jure circa 1995 (0)

Anonymous Coward | more than 9 years ago | (#13205135)

Sorry, there are no silver bullets. Here's a "lifetime acheivement award, anyway".

For OO fans... (4, Informative)

William Robinson (875390) | more than 9 years ago | (#13205187)

This site [ootips] is one of the best.

Re:For OO fans... (0)

Anonymous Coward | more than 9 years ago | (#13205254)

Or perhaps this one: http://www.ootips.org/ [ootips.org]

Re:For OO fans... (1)

Ravatar (891374) | more than 9 years ago | (#13205584)

Thanks for the link, didn't have this one bookmarked.

Oh dear... (3, Insightful)

groman (535485) | more than 9 years ago | (#13205188)

Oh my

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... (1)

putko (753330) | more than 9 years ago | (#13205223)

That happened at UCB? That's terrible news. It wasn't always so, of course.

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... (5, Insightful)

Anonymous Coward | more than 9 years ago | (#13205248)

Of course it isn't Computer Science, it is Software Engineering. The book helps you design software systems. Can Karnaugh maps do that?

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... (0)

Anonymous Coward | more than 9 years ago | (#13205745)

Its not really even software engineering. Most design patterns are nothing more than tricks to get around the limitations of most mainstream OO languages. It's no accident that non object oriented langauges like Lisp and ML don't have quite so many design patterns.

Re:Oh dear... (2, Insightful)

TheGavster (774657) | more than 9 years ago | (#13205265)

As a computer science major, I find it depressing that I only know what half those words mean, and I learned them all in electrical engineering courses. We really need to get back to "Computer Science is highly organized math" rather than "Computer Science is objects".

Re:Oh dear... (1)

be-fan (61476) | more than 9 years ago | (#13205363)

LOL. I find it depressing that I know most of what those words mean, but I'm an aerospace major. I learned most of them in my EE courses and from hanging out on comp.lang.lisp...

Re:Oh dear... (2, Insightful)

aftk2 (556992) | more than 9 years ago | (#13205277)

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.
Interesting - that you decry the popularity of "buzzwords" with a list of what are, essentially, buzzwords.

*ducks*

Re:Oh dear... (1, Insightful)

patternjuggler (738978) | more than 9 years ago | (#13205539)

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.

Interesting - that you decry the popularity of "buzzwords" with a list of what are, essentially, buzzwords.


A buzzword is a fashionable word for something either very simple, or something very vague and un-concrete. It makes you sound a little smarter initially, because the word is more intelligent and exotic sounding than 'thing' or 'stuff' (or whatever). After everyone starts using it more and more frequently in contradictory or meaningless ways, then it becomes a recognized buzzword and makes you sound less educated for saying it.

I rarely hear theorems used as buzzwords, though there are instances when a science popularizer tries to explain a theorem in a mass-market medium and then everybody who read the back cover of the book or caught 5-minutes of the show on PBS will start using it.

I've never heard Karnaugh Map used by anybody who didn't know what it meant, people discussing design patterns typically have read parts of the book but are most likely applying the pattern where it doesn't belong, and if I ever heard someone use the term paradigm seriously in a technical discussion I'd probably laugh in their face.

 

Re:Oh dear... (2, Interesting)

Kupek (75469) | more than 9 years ago | (#13205678)

Programming paradigm. It's the most appropriate word to describe the different families of programming styles/languages: procedural, functional, object-oriented, imperative, logic and such. It's commonly accepted; I've seen it in places ranging from textbooks to CS papers to Stroustrup's C++ book.

Re:Oh dear... (0, Flamebait)

Surt (22457) | more than 9 years ago | (#13205648)

CS snobs just get worked up easily since 9 out of 10 computer related jobs are for engineers rather than CS snobs. In my opinion, really, you should want to learn enough to know both, and to know that no matter how much you read, you'll know less than 1% of what there is to know about computers.

Re:Oh dear... (1)

fishbowl (7759) | more than 9 years ago | (#13205317)

You actually know someone with a CS degree from Berkeley who can't keep up with you on any of those topics? Or are you just guessing?

Re:Oh dear... (3, Insightful)

cratermoon (765155) | more than 9 years ago | (#13205323)

People with CS degrees seem to get jobs writing software for money without knowing a thing about security, testing, defect discovery and removal, team organization, refactoring, design, technical writing, communication, estimating, abstractions and complexity management, business practices, communicating with users... well, anything needed to actually deliver working software that delivers value to the business.

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... (0)

Anonymous Coward | more than 9 years ago | (#13205368)

That is why people with a CS degree shouldn't get software engineering jobs. I have an SE degree and I came out of school knowing much of what you listed (along with other SE topics). However when interviewing I was always asked CS questions.

And we wonder why CS is on the decline.

Re:Oh dear... (1)

justine_avalanche (546756) | more than 9 years ago | (#13205632)

Don't be so quick opposing the computer science theory and software engineering techniques (why would they be mutually exclusive anyway?).
You would be surprised how much knowledge of "turing machines" (finite state machines are used in many algorithms), "functional languages" (what's wrong with them?) or "planar graph" (graph and other data structures knowledge might be the difference between a problem solved elegantly and the same problem solved with a clumsy solution) can actually help in the construction of software.

I'm not sure how Goedel fits in there though ;)

Re:Oh dear... (1)

pilkul (667659) | more than 9 years ago | (#13205920)

You would be surprised how much knowledge of "turing machines" (finite state machines are used in many algorithms), "functional languages" (what's wrong with them?) or "planar graph" (graph and other data structures knowledge might be the difference between a problem solved elegantly and the same problem solved with a clumsy solution) can actually help in the construction of software.

Yep. By a remarkable coincidence, I actually happen to have a summer job working at (guess what!) a trucking company struggling with logistics. I'm using the Filemaker database software --- a pragmatic, business-oriented RAD system if there ever was one. And it so happens that Filemaker's automatic field calculations are written in a functional language, and that Filemaker internally uses graph-theoretic algorithms to trace the dependencies between these calculations.

It should be an obvious point really, but both CS-ish knowledge and SoftEng-ish knowledge is important to be a skilled programmer. (Though I will admit that given a choice between only one or the other type of knowledge, I would choose the SoftEng guy to build my business system...)

Re:Oh dear... (0, Troll)

MPR At UW (840810) | more than 9 years ago | (#13205683)

People with CS degrees get jobs writing software for money because, unfortunately for the rest of the world, software engineers blindly play with mathematical tools which they do not understand. Fantastic, you know how to take two algorithms you don't understand and glue them together as per the template pattern or create objects with a factory, the real problem arises when you have to design an algorithm which requires more than a for-loop and some arithmetic. Read some Dijkstra if you don't want to listen to me, he's much more interesting than the GoF especially if you ever want to write something more thought provoking than an inventory management system or a porn dialer. Go ahead and write $12 shareware for the rest of your life, I'll happily be working on theories you'll use time and time again and never be able to understand but pretend to be the expert on.

MOD PARENT UP (0)

InterruptDescriptorT (531083) | more than 9 years ago | (#13205338)

I, too, read the Gang of Four book. It is treated at my workplace like a Bible of sorts. And it's all a bunch of bullshit. If you want to make your code slow and bulky at the expense of maybe being 5% more maintainable, this is the book for you. However, in the real world, where customers want their software to run fast and use a minimum amount of system memory, these techniques, while instructive, are ultimately utterly worthless. The poster is absolutely right in saying that it's all just OO banging. Kids these days are taught the benefit of a signleton and a bridge pattern, but can't tell you the meaning of priority inversion or when you need to use a spinlock versus a regular sync object.

Re:Oh dear... (3, Insightful)

SirSlud (67381) | more than 9 years ago | (#13205558)

Face it; software is now a commodity business. Using an automotive analogy, if you want to improve the performance or design of the internal combustion engine, go for it, but most software jobs these days only requires putting a kit together rather than having to push the envelope of science.

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.

An Excellent Book (2, Informative)

under_score (65824) | more than 9 years ago | (#13205207)

It surely deserves this award. However, after 15 years doing software development, I now consider two other books even more important even thought they are not quite as information-full as the design patterns book. They are: "Agile Software Development" by Alistair Cockburn and "Software Craftsmanship" by Pete McBreen. I have a full list of books, web sites and tools that I recommend at my Software Resources [berteig.org] page.

An Excellent Book-Plus one (1, Informative)

Anonymous Coward | more than 9 years ago | (#13205474)

The laws of software process: a new model for the production and managment of software by Phillip G. Armour

The Art of Interactive Design by Chris Crawford.

Designing and writing Online Documentation by William Horton.

Technical Editors Handbook by George Freeman and Deborah A Freedman.

Bugs in writing: A guide to debugging your prose by Lyn Dupre.

Re:An Excellent Book-Plus one (1)

under_score (65824) | more than 9 years ago | (#13205735)

Cool - thanks for what I'll take as recommended reading! Always looking for new books to consume, internalize and act upon.

Landmark (0)

cratermoon (765155) | more than 9 years ago | (#13205208)

Congratulations to Erich, Richard, Ralph, and John. Great guys who made a contribution for the ages.

Experience for the unexperienced (1, Funny)

dubbayu_d_40 (622643) | more than 9 years ago | (#13205226)

Common sense for the rest of us. It was a good idiot filter back in the day...

Re:Experience for the unexperienced (0)

Anonymous Coward | more than 9 years ago | (#13205347)

Transfer of information is the essence of authorship; in fact this book goes much further - it transfers wisdom. A very hard and worthy accomplishment.

Re:Experience for the unexperienced (1)

dubbayu_d_40 (622643) | more than 9 years ago | (#13205430)

Dream on.

Excellent material, often taught incorrectly (5, Interesting)

bsandersen (835481) | more than 9 years ago | (#13205231)

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 (2, Interesting)

Brandybuck (704397) | more than 9 years ago | (#13205434)

Instead, what I often see if people spouting pattern names like one would name-drop at a party

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 .NET because "it's enables Reflection."

Re:Excellent material, often taught incorrectly (1)

SirSlud (67381) | more than 9 years ago | (#13205611)

Can somebody please give me a link to a rundown of how reflection improves software engineering? Is it for debugging purposes? To make it easier to write safe code for dynamic classes? I understand the concept, but I still havn't see the killer app.

Re:Excellent material, often taught incorrectly (1)

nebby (11637) | more than 9 years ago | (#13205928)

You can do a lot of useful tricks with reflection when its mixed in with code generation, for what it's worth. Ie, dynamically build a custom class on the fly, compile it on the fly, and then instantiate it on the fly.

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-tensive.com

Another thing we use it for is to dynamically build and hook into older versions of our libraries for building SQL migration scripts. For example, our tool will revert source back to the previous revision, build the stuff, dynamically instantate the class, save the database schema required, roll it forward, build, repeat, and find the "SQL diff" of the two databases which we then tweak for migration purposes. Doing this elegantly and cleanly would not be possible without reflective techniques.

Re:Excellent material, often taught incorrectly (2)

Brandybuck (704397) | more than 9 years ago | (#13205970)

Reflection is a nice pattern. But the ADP book treats it as an *architectural* pattern. As in, it defines the entire structure of your system. Consequently, the architectural team at my work is making a brand new system based on the reflection pattern.

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 (1)

hritcu (871613) | more than 9 years ago | (#13205919)

This was the case only until this book came out: Head First Design Patterns [oreilly.com] . Really an amazing book, I would recommend to anyone who is serious about learning design patterns.

worth it for one reason (5, Informative)

bmac (51623) | more than 9 years ago | (#13205261)

The patterns themselves are not really that
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 (0)

Anonymous Coward | more than 9 years ago | (#13205321)

I haven't read the book, but your retelling of the part where it suggests to prefer composition to inheritance seems a little silly. How do you (they) suggest we implement polymorphism when dealing with composition rather than inheritance hierarchies?

Re:worth it for one reason (0)

Anonymous Coward | more than 9 years ago | (#13205342)

I haven't read the book, but I imagine the book supports the use of inheritance hierarchies for establishing interfaces (or contracts), not for inheriting code.

To confirm you're not a script,
please type the word in this image: [eviller<<</\/\/\]

Re:worth it for one reason (1)

bmac (51623) | more than 9 years ago | (#13205405)

They don't (as I remember) say to avoid
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 functions. I
know it's considered bad-practice, but
it does keep all the code in one place.
Now, if each different type has vastly
different data associated with it, then
true polymorphism is my choice.

Due to the fact that my software projects
get larger every year, I am generally more
concerned with source code management
than cuteness of structure. It seems to
me that keeping everything within one
file and class makes it easier to create
and debug and *edit*. Whether using
ultraedit or vs.net to develop code, my
biggest complaint is how few items on my
tab strip can be seen at one time. When
dealing with the relations between many
different levels of a system, going from
file to file is essential. Of course,
what I really want is to have the file
names organized in layers so that their
source relation (as I visualize it) would
be reflected in the file selection tab.

Of course, that is what my work revolves
around. We programmers must always remember:
if we have complaints about the tools we
use, we should just write our own!

Peace & Blessings,
bmac

Re:worth it for one reason (1)

sean23007 (143364) | more than 9 years ago | (#13205802)

JEdit has a plugin that list all the open tabs in a pane on the right side of the screen. Using that, you can view like 30 filenames at once, compared to only like 8. I use it for all my coding. I just wish it were a bit snappier on OS X, but it flies on Linux.

Re:worth it for one reason (2, Insightful)

Brandybuck (704397) | more than 9 years ago | (#13205400)

Unless of course, cElement is a cParent. In that case inheritance makes sense.

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 (1)

nkh (750837) | more than 9 years ago | (#13205649)

Maybe what the GP meant is that there is too much inheritance without a good reason behind it. I'm reading a book on design patterns right now and they just give you this as a piece of advice, not an order: "don't overuse inheritance when you just need to create a structure." Inheritance is a good thing but in the end you still need members to keep the info and as you said it perfectly "everything has its balance."

Re:worth it for one reason (2, Insightful)

Anonymous Coward | more than 9 years ago | (#13205839)

Unless of course, cElement is a cParent. In that case inheritance makes sense.

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.

An observation... (4, Insightful)

bunyip (17018) | more than 9 years ago | (#13205279)

"Some is good, more is better, and too much is just about right."

- 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... (1)

mudbogger (668451) | more than 9 years ago | (#13205480)

"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." Might be a little too bold of an assumption. A lot of people like myself enjoy using patterns and *gasp* do even look for ways to use them. Doesn't mean the code isn't good; I mean if there are multiple ways to write it and one is based on a standard that there is little wrong with (the particular pattern in question) and the other way is just how you intuitively think about it, the chances are the former will be more beneficial, cleaner, extensible, etc, etc, etc.

Re:An observation... (1)

sean23007 (143364) | more than 9 years ago | (#13205825)

I think what he was referring to was that some "pattern zealots" will go through the list of patterns and try to fit as many as possible into their program. They're operating under the same assumption that you made, that more patterns is better. However, if you are using them just to use them, you run the risk of misusing some of them. And cramming a design pattern into a place where it doesn't quite fit is what leads to bloated, bad code.

Re:An observation... (1)

KidSock (150684) | more than 9 years ago | (#13205925)

Agree 100%. In fact I think OOP in general is overused. OOP is just one of many techniques that can be used in programming. I've done my share of Java and it's a great language but most of the Java code I've seen is so heavily OOP I don't think people even realize that they can occomplish the same task with a few lines of simple C-ish looking code. In the long run I think this will actually hurt Java as a language. A perfect example is log4j. That whole package is riddled with design pattern stuff where a simple PrintStream with a loglevel member would have been perfect for 9/10 apps. And yet it is considered by many people to be gleening example of Java perfection. That's what happends when you put a little marketing behind a programming language. Shrug.

Okay, I'm gonna brag a little... (0, Offtopic)

IronTek (153138) | more than 9 years ago | (#13205293)

Ralph Johnson was my professor for two semester when I took UIUCs CS Senior Prject course the year before last. Pretty good guy! Very laid back.

Good book, too! Well earned, I'd say!

Easily mastering design patterns (4, Informative)

De Lemming (227104) | more than 9 years ago | (#13205372)

The classic Design Patterns book is great, and the GOF certainly deserves this award. Still, the book is hard to read. And in daily practice, it's not always clear when to apply which pattern (especially for the less experienced).

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:Head First Design Patterns (1, Informative)

Anonymous Coward | more than 9 years ago | (#13205517)

Thanks De Lemming, we appreciate it. We stood on the shoulders of gaints to write Head First Design Patterns. You're totally, right, our books are for learning, grab GoF for ref. ;)

Eric Freeman

Re:Easily mastering design patterns (1)

hritcu (871613) | more than 9 years ago | (#13205979)

I have been using design patterns for some years now (in fact everybody who does OOP does, whether they know it or not), but I never had the patience to read a book on the subject. They were so boring and dull, and without the proper examples, I was usually forgeting everything anyway in a couple of days, even before I was applying it into a concrete design.

Now I got admitted into a Software Engineering MSc program, starting this autumn and I really felt I had to improve my design pattern skills this summer. So I started reading this great O'Reilly book De Lemming already told you about (yes, Head First Design Patterns [oreilly.com] ). It is really amazing. Although it is very long, and covers a lot of ground, I never got bored while reading it. On the contrary, I had great time, laughing very often, and implementing every pattern myself in ..... JavaScript (I don't use Java because it would be too easy, and would spoil all the fun :) ). Really an amazing book, I would recommend it to anyone who is serious about learning design patterns.

The problem with patterns (4, Interesting)

be-fan (61476) | more than 9 years ago | (#13205384)

Patterns themselves are good to have in code, but the idea that they must be reimplemented for each case (as opposed to being packaged up into a concrete, first-class language object) really shows the limitations of mainstream languages. Peter Norvig (formerly at Harlequin, and now at Google) did a good writeup [norvig.com] of the issue. Paul Graham also has an interesting take [paulgraham.com] on this subject.

Re:The problem with patterns (1)

SirSlud (67381) | more than 9 years ago | (#13205710)

I get your point, but its as unpractical as the answer, 'roll your own' to the 'are there any good X' questions programmers constantly poll the community for.

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 simply don't have the resources and can't afford the uncertainty of re-examining the axioms of our work environment. In that scenario, its hard to argue that Design Patterns doesn't at least help people get from point A to point B without the trial and error routine.

Re:The problem with patterns (2, Insightful)

be-fan (61476) | more than 9 years ago | (#13205803)

Undoubtedly. Design patterns are helpful in any code, they're just easier to use when the language is properly set up to handle it. Now, it's true that a lot of people can't afford to "non standard" tools. The potential for being blamed if something goes wrong is quite high indeed. However, my point was merely that mainstream languages are not ideally geared towards working with patterns. That does not mean that they'll always be that way, however. Mainstream languages are increasingly ripping entire pages out of the books of dynamic languages (eg: Java 1.5, C# 2.0). Over time, the tools will get better, and looking at what existing dynamic languages do know could give you an edge when the mainstream languages incorporate their features.

Re:The problem with patterns (1)

SirSlud (67381) | more than 9 years ago | (#13205826)

Good point!

Christopher Alexander: The true originator? (2, Informative)

0x1234 (741699) | more than 9 years ago | (#13205615)

When I was in college, an architecture student friend of mine suggested that I read two books by a guy named Christopher Alexander: A Pattern Language (1977) and Timeless Way of Building (1979).

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 and subtle ways. They are not usually designed, but instead are discovered.

Interestly enough, I believe that Alexander himself wasn't an architect, but a physicist with an interest in architecture.

I hope that Alexander was mentioned ;)

Re:Christopher Alexander: The true originator? (1)

russellh (547685) | more than 9 years ago | (#13205832)

yes, alexander is the originator. he is a berkeley professor of architecture. he was honored at OOPSLA in.. 1998? 1997? for his work. richard p gabriel has a good overview of alexandrian patterns wrt software in his book patterns of software [amazon.com] (which Alexander intro'd).

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 pattern language. It's how, not what, which is why the first volume of the one you mentioned is called the timeless way of building. But I will say that it is not obvious how his concepts translate to software at all. for instance, there is no software architecture/design that moves us like, say, the Notre Dame cathedral does; it just doesn't make sense. I'm not moved by anything in the GoF book the way I am by A Pattern Language, despite being a severe programming geek. And I mean not even remotely. The GoF book, while full of fun and useful knowledge, leaves one cold. Perhaps this notion of pattern is all we can do thus far, without the software equivalent of the way.

Finally, Just a few years ago Alexander published his massive 4-volume book, The Nature of Order [amazon.com] that he'd been working on for 15 years or so. Required reading.

Re:Christopher Alexander: The true originator? (1)

dudeman2 (88399) | more than 9 years ago | (#13205879)

Yes. He's cited as an inspiration for software design patterns. He's an actual architect [wikipedia.org] .

Design Patterns are Band Aids for OO programming (0)

Anonymous Coward | more than 9 years ago | (#13205773)

For another take on design patterns, I consider them to be nothing more than tricks to get around the braindead limitations of most mainstream object oriented languages. Its no accident that non object oriented languages like Lisp and ML don't have quite so many design patterns.

Re:Design Patterns are Band Aids for OO programmin (1)

MobyTurbo (537363) | more than 9 years ago | (#13205878)

For another take on design patterns, I consider them to be nothing more than tricks to get around the braindead limitations of most mainstream object oriented languages. Its no accident that non object oriented languages like Lisp and ML don't have quite so many design patterns.
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 object oriented programming, creates his own set of object oriented systems in the final tutorial chapter of his book, "ANSI Common Lisp". (It's easy to build object systems in any language, such as Common LISP or Scheme, which have lambda and lexical scope.)

As for ML, the most popular ML language is OCAML. The "O" in OCAML stands for "objective", guess what that means. It's no wonder you posted as an AC, you obviously don't know anything about Lisp or ML other than what you've read in someones' blog.

Give it to Code Complete, instead... (2, Interesting)

javabandit (464204) | more than 9 years ago | (#13205799)

Seriously. I think some patterns are fine for some things, but as a previous poster has stated, more ugly-as-shit code has been written using design patterns than not.

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".
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>