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


Complete and Await Reply Script

Just in time for the launch of OmniFocus 2 for Mac, here’s an update to my Complete and Await Reply script.

This script marks a selected action as complete and creates a new action, like the selected one but prefixed with “Reply on:” and placed in your Waiting For context. It’s great for email and other actions where you expect a reply but want to make sure you don’t forget to follow up if the reply doesn’t come.

There are lots of changes and improvements to this script beyond OmniFocus 2 support.

  • The script now uses Notification Center.

  • You can use a Waiting context that is a sub-context, instead of just top-level contexts. This was the most commonly reported bug in the script.

  • The script no longer adds a due date to the “waiting for” task. If you prefer the old behavior, there’s a property in the script to set the number of days from now that the new task is due. Just change this line:

    property daysUntilDue : -1


    property daysUntilDue : 3

    to make the new task due in 3 days.

  • The note of the “waiting for” task will get a line that says something like “Reminder sent on May 21, 2014”, so you can keep track of when you sent the email or talked to the person.

  • You can run the script on an already “waiting for” task when you send a follow-up email. A new task will be created, but it won’t have the “Reply on:” prefix added twice; however it will get another paragraph indicating when the follow-up was sent.


To install the script in OmniFocus 2 for Mac, choose Help → Open Scripts Folder. Drag the Complete and Await Reply file into the scripts folder. You can then use Customize Toolbar to add the script to the toolbar in OmniFocus if you like.

Share and enjoy!

(And drop me a note @curtclifton on Twitter to let me know which script you’d like me to update next.)


Scripts for OmniFocus 2 for Mac

At Omni we’re hard at work putting the finishing touches on OmniFocus 2 for Mac. The AppleScript interface for OmniFocus has changed to match the new, more approachable user interface. Unfortunately that means that my collection of AppleScripts for OmniFocus is in need of a tune up.

I’m spending all of my work time and some of my free time on OmniFocus 2 itself, but I’m trying to update my scripts in some of the downtime that remains.

I’ve just posted an updated version of my Populate Template Placeholders script for OmniFocus 2. This script takes an OmniFocus project, replaces placeholder text with user entered strings, and adjusts all dates by some fixed interval to match a new start or due date that you enter. Installation and use instructions are included in the download.


(And drop me a note @curtclifton on Twitter to let me know which script you’d like me to update next.)


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!