Design Patterns in Dynamic Langauges

I went to the Portland JUG meeting this evening to hear Neal Ford talk about design patterns in dynamic languages. Unlike Joshua Marinacci a couple months ago, Neal actually seemed to understand what he was talking about, which was a relief. He gave a quick run-through of dynamic vs. static languages (or ceremonial vs. essential, as he says), and then stepped through a bunch of the GoF design patterns, what they're about, and how they're largely irrelevant in Groovy and/or Ruby because the language provides the "pattern" as part of core language constructs.

What I found most interesting was the different ways that Ruby and Groovy do similar things. While I don't know that I've blogged much about it, those who interact with me in meat-space know all about my aversion for Ruby's ghastly syntax. (I swear Matz was drunk when he was doing the initial implementation and decided it should be a design goal to use every friggin' printable character in ASCII.) Seeing some of it's power compared with Groovy gave me some more appreciation for the language, even if it did nothing for it's appeal. Decorator implementations and method interception were particularly interesting.

Bottom line, however, is that design patterns (at least th GoF's) are incredibly relevant to dynamic languages. In fact, I'd say they're more relevant than ever. With "old" langauge (Java, C++, etc. that the GoF book was targeted at), you could either recognize the patterns and leverage their nomenclature, or you could not recognize them, lose a bit of productivity, but not really be too worse for wear. However, with the dynamic languages having many of the pattern implementations built in, you're really stuck if you don't understand the patterns and what they're about, because you can't use the language without that knowledge.

To use my favorite metaphor (carpentry tools), anyone can use a hammer and a chisel bevel the edge of a board (one specific board, mind you, no retries). It probably won't be very pretty unless you're quite skilled, but anyone can do it given time and patience. Give someone a table router and you've got all kinds of potential to hurt yourself, not to mention chances to ruin their one board, but you can do it quick if you know how. If you don't understand how the more powerful tool works, you're going to be in a world of hurt, but if you can leverage it's strengths, you'll be amazingly better off.

So don't skip the GoF book just because you use a dynamic language. You better know it inside out, just ignore the implementation details.

Comments are closed.