Is INTERPRETER an anti-pattern?

Question

To me, the Interpreter patten sounds very much like an anti-pattern known as Greenspun's tenth rule:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

That is, if you need to use Interpreter, you're likely to create something that's slow, ad-hoc and poorly specified. The right solution is to use the right language from the beginning.

Or, alternatively, embed a well known and well specified language into your application, such as Guile (the GNU embeddable scheme). Or use Haskell as an embedded domain-specific language.

But I haven't seen this in practice--what are your experiences regarding building your own embedded languages? Is it a good idea? Is it better than embedding an already existing language?

(I'm not particularly a lisp fanboy. It's nice, but so's C and Haskell and python and a lot of other languages.)

Answer 1

There's nothing in the interpreter pattern that says it has to be another programming language's syntax that you're interpreting. If you need to parse a simple mathematical expression, then interpreter is just the thing.

Knowing when to use a pattern is what prevents it from being an anti-pattern.

Answer 2

Any design pattern is an anti-pattern if misused.

Good uses of the Interpreter Pattern:

• Software compiler
• SQL evaluation engine
• Graphing calculator input parser
• XML parser

These are all programs that solve the problem of evaluating words in a language, whatever that language may be.