Menu Sidebar
Menu

Avdi Grimm

Hacker; code documentarian.

Sri Yantra Mandala (By N.Manytchkine (Own work) [GFDL (http://www.gnu.org/copyleft/fdl.html), CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/) or CC BY-SA 2.5-2.0-1.0 (http://creativecommons.org/licenses/by-sa/2.5-2.0-1.0)], via Wikimedia Commons)

Patterns are for People

There’s a meme, originating from certain corners of the Functional side of programming, that “patterns are a language smell”. The implication being that “good” languages either already encode the patterns as language features, or they provide the tools to extend the language such that modeling the pattern explicitly isn’t needed.

This misses the point on rather a lot of levels.

First, it usually originates from the widespread identification of “patterns” as a discipline with a single patterns catalog, the “Gang of Four” book. The argument goes like this: “You don’t need the Visitor pattern in a language where you can apply an arbitrary lambda over any collection“.

Personally, I think this misses some important subtleties of the Visitor pattern, but I’ll let that slide for now. The larger point is that many of the patterns in the GoF are intentionally foundational, and some of them do in fact reflect weaknesses in certain formalist OO languages like C++ and Java. This is the seed of truth to the whole argument.

Unfortunately, it’s a case of throwing the baby, the bathtub, and in fact the entire west wing of the house with the bathwater. I have an entire shelf devoted to patterns literature. (This would be a great point to insert a photo, but my books are currently in transit to Tennessee.) Very few of those patterns are foundational or even widely applicable.

Instead, each pattern reflects deep experience with a particular type of problem. Some of them are about financial systems. Some are about signal processing. Some are about games. Some are about enterprise systems.

Patterns are experience reports. They are institutional memory that transcends organizational boundaries. But more than that, patterns reflect how a particular team, or series of teams, managed to come to grips with a particular type of problem.

When I transitioned from writing software for air traffic control systems to writing enterprise software, I came with a set of implicit presuppositions. Assumptions such as: an object can only be constructed in a valid state. Invalid data must be rejected at construction time.

This turns out to work well for systems that consume only feeds from other automated systems. But less well for systems that interact directly with humans. If I had read Ward Cunningham’s CHECKS pattern for interacting with humans, I would have been much better prepared for the new world I was entering. I would have more quickly comprehended the need for ideas like Exceptional Value, a value that is clearly unacceptable but which is still kept around so that it can be presented back to the user for correction.

Much of my research time lately has been devoted to the study of how programmers and teams of programmers erect shared constructions of reality in order to come to grips with a problem. Patterns are a way of capturing these reality constructions for posterity.

In the end it doesn’t even matter that much if you actually create classes in your code named after patterns, or whether you use equivalent language features, or none of the above. A pattern language is a set of complementary thought-forms that helped some people get their minds around a problem. Ultimately they aren’t about the code you write; they are about how you see the problem in your mind’s eye, and the vocabulary you use to talk to your team about it.

Of course, since patterns guide how you conceptualize a problem space, this means they also have a lot of power to lead you down a bad path. You have to remember that in the end, you need to construct a consensus reality that makes sense for your project. The realities of those who have gone before should be instructive, not prescriptive.

Patterns aren’t tools for programming computers; they are tools for programming people. As such, to say that “patterns are a language smell” makes very little sense. Patterns are a tool for augmenting language: our language, the language we use to talk to each other about a problem and its solutions; the language we use to daydream new machines in our minds before committing them to code. Patterns aren’t a language smell; rather, patterns are by definition, [optional] language features.

Where to find me in 2015

The first half of my conference-going year is starting to firm up, so I thought I’d briefly post about where you can find me this year, if you feel so inclined. So far it’s a light year for travel, but I’ll probably be adding a few more dates as the year advances.

March 4-8: Tropical Ruby 2015, Brazil

I feel like this speaks for itself:

5303407659_bf591f8f33_b

If you want to join me here, check out the site. They are also seeking sponsors, in case you represent a company that is looking to invest in the community.

July 20: Brighton Ruby Conference, England

Apparently 2015 has a beach theme. I’m excited about this conference, because after years of passing through Heathrow on the way to somewhere else, I’m finally attending a conference in England itself!

Here’s the website. This conference is seeking sponsors as well!

Beyond July: ???

I’m not actively submitting talks this year. But if you want me to come speak at your conference, or for that matter if you just want me to come and wear silly hats and spend a day pair-programming with attendees, get in touch. Bonus points if your conference has a dance floor.

Tangent: a CoC policy

I was very pleased to see that both of the above-referenced conferences had prominent codes of conduct posted on their websites. This is something that I am now looking for when considering whether to attend a conference (whether I am speaking or not).

As far as why, I think John Scalzi sums it up best:

Because I want my friends and fans to be able to come to a convention and feel assured that the convention is making the effort to be a safe place for them. I want my friends and fans to know that if someone creeps on them, there’s a process to deal with it, quickly and fairly. And I want my friends and fans to know that I don’t support conventions that won’t go out of their way to do both of these things.

As far as details go: basically, Scalzi’s policy is my policy too. If you have any questions, check out his original post and the followup FAQ.

(And a big thank-you to John for, once again, saying sensible things so that I can be lazy and point people to them.)

http://www.dreamstime.com/stock-images-wreck-beach-gili-island-indonesia-image30110494

Who is your failure helping?

True story: I once worked on a project where I was told from the outset that “we probably will not use your code”.

This was back when I worked at a big defense contractor. There were negotiations under way for an expanded contract that would obviate the work I was doing, if it were signed. But someone still had to do the work, to meet current contractual obligations and in case the negotiations fell through.

Back then I estimated that about 50% of the work I did was eventually shelved and never used. Contracts changed, or a feature went over-budget and was cut, or a management shuffle resulted in new priorities. I began to think about projects as being similar to teeth: ignore them long enough and they’ll go away. This environment lead to an interesting productivity optimization: I realized I could ignore projects for weeks on end, and focus on my self-teaching instead. Eventually half the projects would go away, and the rest I could cram out with a few over-nighters.

Read More

Why does Ruby have blocks?

Ruby’s blocks are easily the biggest hurdle most newbies to the language have to overcome. Even for people with years of experience in other languages, the the concept of blocks is often an elusive one at first.

In my opinion, some of the difficulty in grokking blocks can be chalked up to how they are usually explained. In this article, which started out as a post on Parley, I want to explain how I think of blocks: as just a pragmatic shortcut for a pattern you’ve probably already used in other languages.

Read More

In defense of fat tools

Rails has this thing called the “flash”. It’s like a special subset of the session hash. It’s a key/value store with an enforced short lifespan. Stuff you put in the hash lasts for exactly one render or redirect, and then goes away. It’s handy for stuff like notifications. You can set it in the controller:

# ...
flash[:notice] = "Your order has been submitted."
# ...

…and then you can reference it in a view:

<div class="notice"><%= flash[:notice] %></div>

You can then be confident that after the view is shown, the message will go away and not be seen again.

Recently on the Ruby Rogues we talked to Michel Martens about keeping libraries small and simple. It was a good show and he had a lot of good things to say. You should give it a listen.

Read More

Older Posts

Virtuous Code

"The three virtues of a programmer: laziness, impatience, and hubris" — Larry Wall

Books and Screencasts

RubyTapas Screencasts

RubyTapas Screencasts

Small plates of gourmet Ruby code.

Confident Ruby

Confident Ruby cover

32 Patterns for joyful coding.

The Making of Cowsays.com

Confident Ruby cover

Watch me build an app in Sinatra and Rails

Objects on Rails

Objects on Rails

A developer notebook on applying classic Object-Oriented principles to Ruby on Rails projects.

Exceptional Ruby

Exceptional Ruby

The definitive guide to exceptions and failure handling in Ruby.

Archives

Categories