I’m a software developer for The Omni Group in Seattle. I’m also privileged to help manage the internship program at Omni.


PFDS Repository

I created a repository on github to track my work as I go through Purely Functional Data Structures. See my previous post for background. Feel free to clone the repo if you’d like to follow along with the gory details at home. I’ll summarize with posts here and links to the bits I find interesting.


Three Threads

Three threads have been twisting in my mind lately.

I finally read Moseley’s and Marks’s “Out of the Tar Pit” this week. It’s been on my reading list for months (years?), but I’ve been so absorbed in learning, and doing, Cocoa programming for Mac and iOS that I’ve neglected broader topics. Moseley and Marks take on the perennial issue of complexity in software systems. Specifically, they tackle the complexity of understanding, developing, and maintaining software systems as opposed to computational complexity. While they spread the blame for complexity around, mutable state takes the bulk of their scorn. I have some issues with their proposed solution—functional relational programming—in that they discount the complexity of building user interfaces for rich productivity apps like we craft at Omni. That said, I share their concern about mutable state.

Also sitting in my stack of reading material is Okasaki’s Purely Functional Data Structures. The book is a readable survey of techniques for building data structures for functional languages. Most other data structure texts, while claiming to be language agnostic, assume that you’re working in an imperative programming language. Okasaki presents a variety of data structures suitable for (and efficient in) purely functional languages. The book’s examples are in Standard ML with an appendix giving versions in Haskell.

The third thread is the intersection of object-oriented programming and functional programming. William Cook’s OOPSLA 2009 paper, “On Understanding Data Abstraction, Revisited”, reminded me that there’s no reason for the traditional coupling of object-oriented programming languages and mutable state. We can encapsulate data and operations in objects while maintaining a purely functional style. In some sense this is just a higher-order form of functional programming. Instead of passing a single function as a first class value, we pass an object which is a set of functions. As Cook writes:

“Object interfaces are essentially higher-order types, in the same sense that passing functions as values is higher-order. Any time an object is passed as a value, or returned as a value, the object-oriented program is passing functions as values and returning functions as values. The fact that the functions are collected into records and called methods is irrelevant. As a result, the typical object-oriented program makes far more use of higher-order values than many functional programs.”

After discussing the causes of complexity and our current approaches to (attempting to) tame it, they advocate for functional reactive programming, first proposed by Elliott and Hudak, as the way out.

Three threads: mutable state as the source of complexity, functional data structures, and objects as higher order functional values. A sensible way to tie these threads together might be to dive into functional reactive programming. ReactiveCocoa is the likely entry point from here. At some point I’ll likely do that, but I have a much more ill-conceived project in mind now.

I’m going to work through Purely Functional Data Structures, implementing all the data structures and exercises in a functional subset of Objective-C. I’ll write about the results here as I go. I’m interested in discovering what patterns emerge along the way. I hope that somewhere down the line is a development style that fuses functional models and object-oriented views, with functional reactive programming to tie them together. This might prove to be a terrible idea, but I’m looking forward to learning whether that’s true.


Thanks, Team

Team Omni at our last pre-race practice

Thanks to everyone who supported the Leukemia & Lymphoma Society and my efforts with Team In Training. Together we raised over $3,000 to beat cancer. In honor of our co-worker, Team Omni raised over $14,000. Those numbers are a testament to your generosity. Thank you!

The race went well. I was happy to finish the race with a time of 4 hours, 9 minutes. It was a perfect Seattle summer day, which made for hot running over the last few miles. Thinking about Jacob, Chris, Joyce, Bill, Pete, Ruth, Becky, and all the others who have battled or continue battling cancer gave me strength to keep going. After a week of rest, I laced up my running shoes and hit the road again this morning.

Thanks again for your support. Go Team!


Team in Training

I was shocked and saddened at the end of January to learn that a friend and co-worker had been diagnosed with lymphoma. It’s hard to know what to do when stuff like this happens. Beyond being supportive, helping with meals, and just hanging out, I felt like I wanted to do something to fight back against cancer.

Some other Omni folks were familiar with the Leukemia and Lymphoma Society’s Team in Training program. After learning more about the program and the organization, several of us signed up to run the Seattle Rock-n-Roll Marathon to raise money to find a cure. My personal goal is to raise $2,000.

I’d love to have your support in reaching this goal. Please check out my fundraising page and help if you are able.

Thank you!

— Curt


An Updated 1Password Emergency Kit

As part of setting up my retirement accounts and life insurance at Omni, I’d been thinking about estate planning issues like wills and living wills. Mike Vardy’s 1Password Emergency Kit reminded me that it’s important to make your passwords available to your family and executor. (Head over to Agile Bits for more info on 1Password.)

Mike’s kit is a solid basic document, but I was uncomfortable with some ambiguities in the wording. I also wanted to add blanks for recording log-in passwords for my devices. After all, if my hard drive is encrypted (and it is), then just having my 1Password master password wouldn’t do anyone any good.

Thankfully, Mike provided his document under a Creative Commons license. So, here’s my version, also under a Creative Commons license.

Curt’s 1Password Emergency Kit

Don’t fill this in electronically. That wouldn’t be secure. Instead, print it, fill it in, and store it in a secure fire safe or safe deposit box. (My understanding is that a safe deposit box won’t be accessible by your executor until after the reading of your will. If that’s an issue for you, then the fire-safe option might be best. I’m not a lawyer and nothing here should be construed as legal advice.)