views:

293

answers:

4
+4  Q: 

Idiom vs. pattern

In the context of programming, how do idioms differ from patterns?

I use the terms interchangeably and normally follow the most popular way I've heard something called, or the way it was called most recently in the current conversation, e.g. "the copy-swap idiom" and "singleton pattern".

The best difference I can come up with is code which is meant to be copied almost literally is more often called pattern while code meant to be taken less literally is more often called idiom, but such isn't even always true. This doesn't seem to be more than a stylistic or buzzword difference. Does that match your perception of how the terms are used? Is there a semantic difference?

+2  A: 

Since if you put 5 programmers in a room they will probably not even agree on what things are patterns, there's no real "right answer" to this.

One opinion that I've heard once and really liked (though can't for the life of me recall the source), is that idioms are things that should probably be in your language or there is some language that has them. Conversely, they are tricks that we use because our language doesn't offer a direct primitive for them. For instance, there's no singleton in Java, but we can mimic it by hiding the constructor and offering a getInstance method.

Patterns, on the other hand, are more language agnostic (though they often refer to a specific paradigm). You may have some infrastructure to support them (e.g., Spring for MVC), but they're not and not going to be language constructs, and yet you could need them in any language from that paradigm.

Uri
Yes, there is no "truly right" answer and I've tagged the question as subjective. The most useful (for me) and well-reasoned answer will get accepted. :)
Roger Pate
That makes sense. I was expecting to see 5 "make it a community wiki" comments :) It is a great question though, I'm not sure why nobody else answered yet. Must be a slow Saturday.
Uri
Around half of the design patterns documented by the Gang of Four are simply language constructs or idioms in dynamically typed languages with first class functions.
slebetman
When Norvig analyzed GoF he found "16 of 23 patterns invisible or simpler" in Dylan and Lisp. That's more than half. :-)
Ken
@slebetman: I agree. I think a clear separation (and less C++ focus) would have been great for the GOF book, but it was really the first book on this topic. They probably would have written it differently today.
Uri
+5  A: 

Idioms are language-specific.

Patterns are language-independent design principles, usually written in a "pattern language" (a uniform template) describing things such as the motivating circumstances, pros & cons, related patterns, etc.

Jon Reid
Are you sure you're not just describing the book since I linked to it? For example, "Curiously Recurring Template Pattern" has pattern right in the (very popular) name, but, AFAIK, is entirely C++-specific. Is it just an outlier?
Roger Pate
CRTP may be an unfortunate name in more than one respect. Since Coplien wrote it before the GoF book came out, I can't blame him for using the word "pattern." But if I see something called a pattern, I expect it to be described in some kind of pattern language.
Jon Reid
@Roger Pate: If Jon Reid hadn't beaten me to it, I'd have written something very similar, without having looked at your books. Ah heck, I'm gonna go write something anyway.
Carl Smotricz
+4  A: 

Contrary to the idea that patterns are language agnostic, both Paul Graham and Peter Norvig have suggested that the need to use a pattern is a sign that your language is missing a feature. (Visitor Pattern is often singled out as the most glaring example of this.)

I generally think the main difference between "patterns" and "idioms" to be one of size. An idiom is something small, like "use an interface for the type of a variable that holds a collection" while Patterns tend to be larger. I think the smallness of idioms does mean that they're more often language specific (the example I just gave was a Java idiom), but I don't think of that as their defining characteristic.

Laurence Gonsalves
Agree. I personally use the definition that an idiom is a commonly used and generally understood pattern that can be summed up in 3 lines of code or less.
slebetman
While I agree that patterns tend to be holes in languages, I think there is something to language specificity here. I know of many "patterns" that span many languages, but I know of almost no "idioms" that do, except very similar languages like C and C++. HLLs like Lisp and Dylan don't tend to share GoF's "patterns", true, but if you're in the middle of C# country, those languages are already exceptions to every rule. :-)
Ken
@Ken: Like I said in the answer, "I think the smallness of idioms does mean that they're more often language specific ... but I don't think of that as their defining characteristic."
Laurence Gonsalves
+3  A: 

When people observing program development from On High (Analysts, consultants, academics, methodology gurus, etc) see developers doing the same thing over and over again in various situations and environments, then the intelligence gained from that observation can be distilled into a Pattern. A pattern is a way of "doing things" with the software tools at hand that represent a common abstraction.

Some examples:

  • OO programming took global variables away from developers. For those cases where they really still need global variables but need a way to make their use look clean and object oriented, there's the Singleton Pattern.

  • Sometimes you need to create a new object having one of a variety of possible different types, depending on some circumstances. An ugly way might involve an ever-expanding case statement. The accepted "elegant" way to achieve this in an OO-clean way is via the "Factory" or "Factory Method" pattern.

Sometimes, a lot of developers do things in a certain way but it's a bad way that should be disrecommended. This can be formalized in an antipattern.

Patterns are a high-level way of doing things, and most are language independent. Whether you create your objects with new Object or Object.new is immaterial to the pattern.

Since patterns are something a bit theoretical and formal, there is usually a formal pattern (heh - word overload! let's say "template") for their description. Such a template may include:

  • Name
  • Effect achieved
  • Rationale
  • Restrictions and Limitations
  • How to do it

Idioms are something much lower-level, and usually operate at the language level. Example:

*dst++ = *src++

in C copies a data element from src to dst while incrementing the pointers to both; it's usually done in a loop. Obviously, you won't see this idiom in Java or Object Pascal.

while <INFILE> { print chomp; }

is (roughly quoted from memory) a Perl idiom for looping over an input file and printing out all lines in the file. There's a lot of implicit variable use in that statement. Again, you won't see this particular syntax anywhere but in Perl; but an old Perl hacker will take a quick look at the statement and immediately recognize what you're doing.

Carl Smotricz