Patterns are signs of weakness in programming languages.
When we identify and document one, that should not be the end of the
story. Rather, we should have the long-term goal of trying to understand
how to improve the language so that the pattern becomes invisible or
unnecessary.
Design patterns of
1972
While I've heard of the Gang of Four
and their book, Design Patterns, I've never quite understood all the hoopla over
it—the whole concept seemed pretty silly, or too obvious, to warrant a whole
book on the subject. And it seems like I'm not the only one to think that as
well, and I agree with the author, design patterns are silly.
You have my permission to link freely to any entry here. Go
ahead, I won't bite. I promise.
The dates are the permanent links to that day's entries (or
entry, if there is only one entry). The titles are the permanent
links to that entry only. The format for the links are
simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are
interested in, say 2000/08/01,
so that would make the final URL:
https://boston.conman.org/2000/08/01
You can also specify the entire month by leaving off the day
portion. You can even select an arbitrary portion of time.
You may also note subtle shading of the links and that's
intentional: the “closer” the link is (relative to the
page) the “brighter” it appears. It's an experiment in
using color shading to denote the distance a link is from here. If
you don't notice it, don't worry; it's not all that
important.
It is assumed that every brand name, slogan, corporate name,
symbol, design element, et cetera mentioned in these pages is a
protected and/or trademarked entity, the sole property of its
owner(s), and acknowledgement of this status is implied.
![[The future's so bright, I gotta wear shades]](https://www.conman.org/people/spc/about/2023/1023.t.jpg "The future's so bright, I gotta wear shades")