<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.18.3">
</HEAD>
<BODY>
On Wed, 2008-08-06 at 19:34 -0700, Kevin Scaldeferri wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
> These would fall more under the heading of "idioms" than GoF-style  
> patterns in my books (although the latter of the two is in the same  
> grey space I mention below).
</PRE>
</BLOCKQUOTE>
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Indeed, it's tough to say exactly what the distinctions are between  
"idioms", "design patterns", and "best practices".  And what is idiom  
in one language may be a pattern in another.
</PRE>
</BLOCKQUOTE>
<BR>
Well, I guess it's the same as the difference between tactical, operational or strategic command: scope of focus.<BR>
<BR>
To me an "idiom" involves a pretty local, narrow focus.  The canonical C++ example is the <TT>auto_ptr</TT> while the canonical Ruby example would be the <TT>||=</TT> initialization trick.  A "pattern" on the other hand has broader scope that impacts the way the whole is built and functions.  Even the Singleton pattern that I squint at as something that is perhaps not quite a "pattern" in my books impacts several things application-wide (specifically the way one or more objects are made).  Another one that I squint at suspiciously -- the Class Factory -- falls too into this.  Use of this pattern affects the way everything else that interacts with it has to be coded.  This is in no way the case (except for the missing bugs, naturally) when you look at <TT>auto_ptr</TT> or <TT>||=</TT>.<BR>
<BR>
As to "best practices" -- I find those to be generally social constructs that impact code, not architectural elements.<BR>
<BR>
But yes, I agree fully that an idiom in one language is a pattern in another.  The GoF Iterator and Visitor are such beasts.  In C++ or Java they're patterns.  In Eiffel or Dylan they're idioms.  In Haskell they're so trivial you don't think about them as anything special beyond "it's the way you do it".<BR>
<BR>
The OP did bring up an interesting point: I have to confess that I now disagree with the reference I sent that said you don't need GoF-style patterns in the functional world.  The OTP <B>is</B> a collection of GoF-style patterns for Erlang.  It's just way more abstract and sophisticated a pattern and I failed to see the forest for the trees as a result.  Monads in Haskell are the same deal, as are the various continuation-passing approaches in various functional languages.  I stand, hereby, corrected.<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
<B>Michael T. Richter</B> <<A HREF="mailto:ttmrichter@gmail.com">ttmrichter@gmail.com</A>> (<B>GoogleTalk:</B> ttmrichter@gmail.com)<BR>
<I>Never, ever, ever let systems-level engineers do human interaction design unless they have displayed a proven secondary talent in that area. Their opinion of what represents good human-computer interaction tends to be a bit off-track. (Bruce Tognazzini)</I>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>