From ... From: Erik Naggum Subject: Re: Design patterns as a weapon Date: 1999/11/28 Message-ID: <3152793877299974@naggum.no>#1/1 X-Deja-AN: 554086663 References: <382C2EED.AE9361C0@computer.org> <382C711F.636A3B5B@computer.org> <38319a69$0$230@newsreader.alink.net> <1e1ij0s.9hmobm185jt74N%schuerig@acm.org> <1e1j8m6.1tx094q13kf59sN%schuerig@acm.org> <1e1ozs2.1jkouw410nom3gN%schuerig@acm.org> <3152787684905454@naggum.no> <1e1zmo9.v1p0yl103z60wN%schuerig@acm.org> mail-copies-to: never X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 943805123 8489 195.0.192.66 (28 Nov 1999 16:05:23 GMT) Organization: Naggum Software; +47 8800 8879 or +1 510 435 8604; fax: +47 2210 9077; http://www.naggum.no NNTP-Posting-Date: 28 Nov 1999 16:05:23 GMT Newsgroups: comp.lang.lisp * Michael Schuerig | I disagree with your premise. You can't cut and paste patterns. huh? I'm saying that people who aren't very good at abstraction write _code_ using cut-and-paste techniques and that patterns fit this mode. this is obviously different from cutting and pasting "patterns", which I find to be a nonsensical statement -- it's like saying that you can't copy somebody's idea because Xerox machines don't work that way. | This notwithstanding, patterns do help abstraction. The abstraction is | not expressible in the code itself, but it can be identified and | documented. Before the advent of explicitly codified patterns these | abstractions would most of the time have gone unnoticed! In this way, | patterns pull the level of discourse toward more abstraction. This | conclusion may not apply to the Lisp programming community, but it fits | the C++ and Java communities very well (I can't tell for Smalltalk). I think you might want to read my article again, since this doesn't seem as if you're doing anything but try to re-phrase what I said in a light somewhat more favorable to patterns. incidentally, I'm strongly ambivalent on patterns. I hate them if they are used to destroy our ability to solve problems once and for all without the need for the repetitiveness of reimplementing them verbosely all the time, and that is a recurring argument in their _favor_ by people who think that most complex problems don't actually _have_ solutions. I love them if they are used to keep people who can't write good code from writing really bad code. ideally, we should get rid of the people who can't write good code, and thus raise the average and our concept of what "can't write good code" means, then keep doing this iteratively until programming became a serious profession with social responsibility. #:Erik