Apr 04 2013


Abstraction or Leverage?

A colleague of mine recently accused me of speaking too precisely. He was giving me a bit of grief, but I took it as a compliment. In this industry, we torture words until they give up all meaning. Keep your eyes open for the next time you read the word "significant." Does it actually refer to something that signifies? Or is it just salt, sprinkled in for flavor?

One of the words I see overused is "abstraction." I hear developers use it when they talk about the DRY principle and reducing common code. Reducing common code to eliminate repetition improves your leverage, but not necessarily abstraction. Leverage allows you to make a change in one place that affects all uses.

As an example, think about one of my favorite code-eating patterns in OO: the Null Object pattern. It concentrates a lot of "if not null" code into one place, which means you can change the logic in that one place. That's leverage: you can make a small changes with large-scale effects.

"Extract method" and "extract superclass" transformations fall into this camp. They add leverage, which is useful.

By drawing this distinction, I'm not criticizing leverage. It's useful and important. But there's an additional thing to consider. When you extract common code to gain leverage, you have little ability to ignore details. Indeed, the specific case is often tightly coupled to the implementation of the general case.

(I will admit that when I distill code down this way, it sometimes clears away the cobwebs enough to see the abstraction that was lurking in the corner. That's always a lovely feeling. So leverage can lead to abstraction.)

The essence of abstraction is cleaving. Abstraction separates a manifold thing into independent concepts. By separating the concepts, it also allows us to see connections between things that share one of those concepts. So abstraction also illuminates connections between things.

For example, consider Clojure's seq (pronounced "seek") abstraction. It calls out the concept "Sequential Iteration," thus bringing together everything that acts like an ordered sequence that can be walked. At the same time, it separates that concept from others. For a vector, seq separates that concept of "Sequential Iteration" from the concepts of "Random Access," "Stacklike Object," and "Lazy Evaluation." For a string, seq separates "Sequential Iteration" from "Unicode Storage" and "Regex Matching." That's the part about separating a manifold thing. At the same time, "seq" shows us that there is an important characteristic shared across all those implementations.

In each case, the abstraction allows us to emphasize a particular aspect of the thing while disregarding the rest. This is the dual nature of abstraction: it obscures and reveals.

As it happens, good abstractions also provide leverage, because they separate concerns. I think this is why the words get conflated. All abstractions offer leverage, but not all leverage is an abstraction.

As you work on your designs, think about where you can split those conceptual atoms. What ideas can you separate? How can you then reconnect the shared concepts?

Apr 01 2013


Where to Find Relevancers: April Edition

Want to meet a Relevancer in person? Here's where you can find us during the month of April:

Philadelphia, PA 4/2-4/4
Emerging Technologies for the Enterprise
Speaking: Stuart Sierra: Clojure/ClojureScript: One Language to Rule the Web

St. Augustine, FL 4/4-4/5
Ancient City Ruby
Speaking: Russ Olsen: Insight, Intuition and Programming

Panama City Beach, FL 4/11-4/14
Attending: Maggie Litton, Ben Vandgrift, Marc Phillips, Ryan Neufeld, Kevin Altman, Sam Umbach

Durham, NC 4/16
West End Ruby Hack Night @ Relevance HQ
Attending: Sam Umbach, Yoko Harada

Alexandria, VA 4/23 @ 6pm
ClojureDC Meetup Group
Speaking: Bobby Calderwood: Datomic

Durham, NC 4/25 @ 7pm
Triangle Clojure Meetup Group @ Relevance HQ
Pedestal Q&A Leader: Ryan Neufeld
Attending: Chris Redinger, Daemian Mack

Columbia, SC 4/25-4/26
Attending: Ben Vandgrift

Portland, OR 4/29-5/2
Speaking: Yoko Harada: Datomic, From Ruby, From Rails
Attending: Jamie Kite, Lake Denman

Mar 22 2013


Quick Bits from Speakerconf

You know how one of the best parts of any conference is the "hallway track?" Speakerconf is designed to maximize that experience: conversation shaped by talks, but with more opportunity for many-to-many communication.

The speakers are diverse and so are the topics. I thought I would share some of the more interesting references that came up during our discussions.

  • LEDBAT (RFC 6817). "Lower-than-best-effort" data transfer reduces congestion by deliberately adding latency.
  • libutp - The uTorrent transport protocol library, which implements LEDBAT.
  • Iranian weavers deshredding documents from the U.S. embassy in Tehran in 1979, and the DARPA challenge from 2011.
  • crazyegg - a service for heat mapping overlays on web pages.
  • Computational Tree Logic - an extension of first-order predicate logic to cover future universes. Quantifiers include "there exists at least one universe in which!"
  • As We May Think - An enormously influential essay by Vannevar Bush.
  • Generalizing Monads to Arrows - One of John Hughes' many excellent papers about abstraction.
  • Probabilistic Graphical Models - A method for integrating uncertain beliefs to estimate likelihood of outcomes, like Bayesian networks on steroids.
  • Composing Contracts - A paper by Simon Peyton-Jones on using combinators in a functional language to model financial instruments.
  • Five flavors of logic: miniKanran, cKanran, alphaKanran, and a couple more that I can't remember.

As you can imagine, it was a stimulating week. Thanks to Jay Fields and Josh Graham for organizing it, and a special thanks to the sponsors Forward, innoQ, and DRW Trading who make it possible.

Mar 18 2013


Tim Ewald on Pedestal - Podcast Episode 027

cover art

As this post goes up, Tim Ewald and Stu Halloway are on stage at Clojure/West unveiling Pedestal, a set of open source libraries for writing web applications and services in Clojure. We here at Relevance have been hard at work on it for months, and we're extremely excited to be able to finally share it with the world.

In this episode, I talk with my close friend Tim about what Pedestal is, why we wrote it, and what makes it so interesting. Enjoy!

Read More »

Mar 01 2013


Feb 19 2013


Alex Redington - Podcast Episode 026

cover art

If you've listened to the show more than once or twice, you've probably heard us mention pair programming. One of the things that people often ask us is how we make that work when so many of us are remote. So I thought that it would be good to talk with someone with whom I have done a fair amount of very successful remote pair programming: Alex Redington. The result was this episode, in which we talk about the various tools and pairing behaviors we use. And about setting things on fire.

Read More »

Feb 18 2013


Hash Maps as Mini State Machines

While working with Ryan Neufeld last Friday, we came across a problem that I had experienced more than once in my programming career: how to toggle a hash map value between two (or more) states.

As a starting example, let's assume that we have a hash map that contains a single key/value, and that we want to toggle the value between -1 and 1. We could write the function thusly:

(defn toggle-value [m]
  (update-in m [:value]
    (fn [v]
      (if (>= v 0)

Now while this code will work, it's not exactly elegant, nor concise. And if we had more than two states (-1, and 1) then we would be forced to change the "if" into a "case" (or a "cond") and then add more and more state transitions to the "if" expression, and our already ugly code would get that much uglier.

It was at this part of my pairing session with Ryan that I remembered an old trick from when I first learned to program in QBasic (more than a few years ago). The trick was that multiplying either -1 or +1 by -1 will cause the resulting value to "toggle" between the two numbers. Actually this works for any states that need to toggle between -N and N, but we'll use -1 today to demonstrate:

(defn toggle-value [m]
  (update-in m [:value] (partial * -1)))

This code is much more concise, but perhaps not as clear. However, for the problem Ryan and I were dealing with on Friday, we couldn't use numbers: we needed to use keywords. We had two states: ":checked" and ":unchecked" and possibly nil. We needed a clear, concise way to toggle between these three states, without writing an ugly case/cond block. In my mind I thought, "we need a function that will return a new state, given an old state. A function that takes a single arg, and returns the new state value." And then I remembered: "Clojure hash maps are functions! And they take a single value (key) and return a single result (value)." Well then, we can write our state transitions with this little bit of code:

(def toggle-states
  {:checked :unchecked
   :unchecked :checked
   nil :checked})

(defn toggle-value [m]
  (update-in m [:value] toggle-states))

This is what I consider good Clojure code. It's simple, clean, concise, and easily extensible. And hopefully it comes in as handy for you as it did for me.

Feb 14 2013


GOTO Night on 2/25 with Michael Nygard!

We're pleased to announce that Michael Nygard will be the featured speaker at GOTO Nights in Chicago on Monday, February 25. Space is limited, so sign up today.

Chicago, IL 2/25/2013, 5-7:30pm
GOTO Night - Devops Night
Speaking: Michael Nygard

In the mean time, check out Michael's interview with Michael Floyd from QCon 2012 about Redefining CAP.

Feb 11 2013


Two Recent Talks

Video for two of my recent talks has gone live. Here they are!

Whence Complexity

As programmers we grapple with complexity. Whether we classify it as "essential" or "accidental" complexity, we all agree that complexity is poison. At the same time, as living beings, we are sustained by complexity. Complexity allows us to sustain our existence far from thermal equilibrium. In natural systems, complexity produces robustness. In human-created systems (whether information, social, political, or economic) complexity tends to create fragility and extreme non-linear responses to stimuli.

At Clojure/conj last November, I discussed the origin of complexity as the result of ongoing dynamic processes.

Thanks to some last-minute calculations about spherical chickens, there was also an excessively vivid mental image included, for which I apologize.

This one is on Youtube.

Loopholes in CAP

Last November, I also spoke at QCon San Francisco on the subject of the CAP Theorem (a.k.a. Brewer's Conjecture.) CAP says that, of the three qualities of "consistency", "availability", and "partition-tolerance", a distributed system can achieve at most two.

I have to confess that this was a particularly nerve-wracking talk, because I followed Eric Brewer on to the stage. Yes, that Eric Brewer, he of the Conjecture itself and one of the field's top experts.

CAP went from "conjecture" to "theorem" in 2002, when Seth Gilbert and Nancy Lynch proved it. And, thus, a thousand database products were launched. Like any theorem, though, there are subtleties to consider. In this playful talk, I look at all the assumptions underlying CAP and try to violate them all, with examples from real systems.

You can see this talk at

Feb 01 2013


Where to Find Relevancers: February Edition

Want to meet a Relevancer in person? Here's where you can find us during the month of February:

Durham, NC 2/9-2/10
Girl Develop IT - RDU Intro to JavaScript & jQuery @ Relevance HQ
Attending: Lynn Grogan

Raleigh, NC 2/12
Triangle.rb Meetup Group
Attending: Daemian Mack

Atlanta, GA 2/18-2/19
Speaking: Stu Halloway
Talk 1: Simulation Testing
Talk 2: Concurrent Programming with Clojure
Talk 3: Clojure in the Field

Durham, NC 2/19
West End Ruby Hack Night @ Relevance HQ
Attending: Sam Umbach, Yoko Harada, Daemian Mack

Charlotte, NC 2/20
Charlotte Ruby Meetup, Lightning Talks
Hosting: Ben Vandgrift

Durham, NC 2/28
Triangle Clojure Meetup Group @ Relevance HQ
Attending: Daemian Mack

Popular Tags