Why not? I realized that I wasn’t enjoying the development process, and recognized the feeling from when I burnt out at Microsoft years ago. This gives rise to two theories: (1) Programming just isn’t for me and this second burnout shows that I should find a completely different line of work. (2) Programming itself isn’t the problem, it’s the surrounding circumstances: at Microsoft the problem was that I had no life to balance my work; now (perhaps) the problem is that I’m working alone, and I’d rather be part of a team. I haven’t decided which theory I think is right.

What now? Good question. I’ll probably wind up with a day job of some kind while I try to sort out longer-term plans. I hope to finally attend a workshop or two at Centerpoint, which I’ve wanted to do for years.

What about this blog? I enjoy blogging and I plan to resume posting on a regular basis in September. With my move away from indie development, the focus will naturally shift, so if you’ve been reading this for the programming-geek content, you may be disappointed. I can’t say much about what will replace it ’cause I don’t know myself yet.

Learning takes time. There’s no getting around it. I’m not just talking about the direct time it takes to learn something, but also the false starts and fruitless investigations that go along with it.

Last week I thought up a couple of different ways to handle custom columns in Trifle. I picked a solution and spent several days coding it. This week I realized that it was the wrong choice; the other way would be simpler and easier. So I had to rip out the work I’d done and start over.

Or take Core Data. Trifle is an awfully database-ish app, so I had to investigate whether Core Data made sense for it. I’ve learned quite a bit about Core Data now, in multiple stints, but it still isn’t the right choice for Trifle.

I could call that wasted time, but it isn’t, really. It’s just part of the overhead of learning to operate in a new environment. Besides, learning is one of my favorite things to do. Maybe that’s what attracted me to programming in the first place: there’s always something new to learn.

At the implementation level, each collection tracks two sets of exceptions. One set contains items to always include, because the user put them there. The other set contains items to always exclude, because the user took them out. There are a few corner cases that get tricky, but overall, it’s not too hard to do the right thing.

This approach abolishes the distinction between regular collections and smart collections. Instead, those two cases become endpoints of a continuum. A regular collection is just a collection with no rules (only exceptions!). A smart collection is just a collection with no exceptions (only rules).

Now that I’m thinking in these terms, I’ve realized that this is part of the plan for Chandler’s collection model. So this isn’t an original idea. That’s a good thing, though: if nobody was using this model, I’d drive myself crazy trying to figure out what fatal flaw kept people from using it in their apps.

Declarative rules are the success story of end-user programming. Millions of nonprogrammers create and use them daily. But in the form of smart playlists (and their smart-* kin), they have some problems. For instance, they make it hard to fine-tune their contents. If the query for a smart playlist gets you almost there, the only way to get all there is to either tweak the query some more (add or remove conditions) or tweak some items (change them to fit/not fit existing conditions). The Chandler folk have been wrestling with this, trying to come up with a more flexible model.

Imperative rules are much more flexible. Lotus Agenda provided powerful imperative rules that could be triggered by various actions. But that power and flexibility had a price. As Agenda’s creators said, “The results of cascading program-initiated actions often surprise even experienced users…” And surprise is a Bad Thing here.

So I’m not happy with either approach at the moment. To use Adam Bosworth’s terminology, declarative rules are simple but not sloppy, while imperative rules are sloppy but not simple.

“Rules are a major schedule risk.” Yes, but I’m not on a particularly tight schedule. Sure, I want to ship expeditiously, but a few months either way won’t make a big difference.

“Rules need to be done right or not at all” — otherwise I’d be stuck supporting a broken rule model. But I think this is actually an argument for rules. By designing rules now, in concert with Trifle’s overall data model, I have a better chance of making a single coherent system.

“Trifle will still be a useful application without rules.” True. But the question is whether Trifle will be a distinctively interesting application without rules. I doubt a simple list/table editor would generate much if any buzz, and for a shoestring operation like mine, no buzz means no sales.

Besides, the whole reason I started this experiment of independent development was to create an innovative and useful app. If I reduce that to a lowest common denominator by eliminating the tricky-but-interesting features, not only will I fail to excite potential users, I’ll fail to excite myself. And that will quickly suck all the fun out of this (ad)venture.

So now I’m in design mode, trying to find a rule model that works. It’s a frustrating endeavor, ’cause I don’t like any of the solutions I’ve found so far, and I don’t feel like I’m making much progress. But that, too, was part of the reason I started doing this: to find a challenge.

AppleScript, though, is far from my favorite programming language. Thank goodness there’s appscript, a bridge that lets you use Python to script AppleEvents. Appscript can’t paper over all the oddnesses of AppleScript, but life becomes much easier with all of Python at my disposal.

For instance: I can drop down to the Objective-C level to verify something using PyObjC. I can use any of several test frameworks. And I can verify saved Trifle documents using Python’s XML support. This is Python’s sweet spot: libraries to connect to just about everything.

Some features are easy to cut. Group-by-column doesn’t fit Trifle’s nonhierarchical model. Automator actions will be easy to add later. Comment popups are just window dressing.

But of course there had to be a big difficult cut that’s hard to do but probably the right thing. And that, in this case, means rules. Rules are central to what I want Trifle to be. Rules are phenomenally useful. And rules need to be cut from Trifle 1.0 because (a) they’re the biggest schedule risk, (b) they need to be done right or not at all, and (c) Trifle is still a useful application without them.

Rules are a major schedule risk because their design is still awfully murky. I don’t even know whether they should be imperative or declarative—at this point, I dislike both choices. But in whatever form they take, rules will require a bunch of extra UI, which means more design work, and more potential slippage.

Rules need to be done right or not at all. If I pick a rule model and a UI and ship them with Trifle 1.0, and later realize they should have been completely different, I’m still stuck supporting the original model.

Trifle will still be a useful application without rules. You’ll still be able to make and manage lists and tables, and do simple calculations like totaling a column. There just won’t be that extra layer of automation that rules provide. Even without rules, though, normal scripting support should allow for plenty of automation.

So here I am trying to talk myself into a major feature cut. It’s discouraging, but I think it’s the right thing. At least I can console myself by dreaming of rules in Trifle 2.0.

• Abstraction mechanisms — not just simple expressions.
• Simple, approachable syntax — People with only a smidgeon of programming experience should be able to do basic things with it. (There will be a dropdown-list UI wrapper for those with no programming experience.)
• Sandbox security — rules will be saved in Trifle documents, and I don’t want macro viruses on my hands. Those who need more power can hook into Trifle via AppleScript or another external scripting language.
• Small and embeddable — in particular, a clean and usable C interface.

F-Script and Tcl fail the syntax test; regrettably, so does Scheme. AppleScript isn’t sandboxed (plus it’s just a little too funky for its own good). The plausible prospects, as I see them, are Lua, Io, and JavaScript.

Lua was made for this scenario. It’s tiny, easy to compile, and simple to embed. Somehow, though, it always manages to rub me the wrong way. For instance, the distinction between dot and colon for accessing objects constantly trips up folks coming from other languages.

Io was inspired by Lua, but emphasizes simplicity and regularity of syntax (perhaps to a fault). I find it very attractive, not least because Io expressions look an awful lot like spreadsheet formulas. But it has a small user base, and still hasn’t quite hit 1.0.

JavaScript is the elephant of this bunch (or would that be the rhino?). It’s probably bigger than Io or Lua, but it’s available in a standard Mac OS X library (WebKit), so I wouldn’t have to ship it. The syntax is full of C-isms, but it’s so widely known that wouldn’t be much of a problem. And the security sandbox is heavily tested.

Anyway, Trifle has reached dogfoodability (dogfoodableness?). There are no columns or rules yet, just lists—but that’s enough for simple task lists, and that’s what I’m using it for. I ported over my GTD stuff this afternoon.

I won’t be working on Trifle itself for the next couple of weeks, but I’ll be using it. No doubt I’ll accumulate quite a list—in the form of a Trifle document, of course—of things I want to tweak, extend, and fix.

That took the question to another level: what XML format should I use? My instinct was to find and use an existing XML vocabulary, rather than invent my own. Tim Bray reinforced that with Don’t Invent XML Languages.

But none of Tim’s Big Five fit the task. DocBook, ODF, and UBL weren’t even in the neighborhood. Atom could just barely work, but only if I added a bunch of extensions in a separate namespace. An XHTML microformat like XOXO could be made to work by shoehorning everything in, but my goals don’t match those of the microformat folk. (For instance, I don’t want to support presentability—these are data files.)

RDF is a better match for Trifle’s graph semantics, but RDF/XML is a pain to use and process. In fact, using RDF/XML would effectively shut out a lot of XML tools. I checked out Turtle as a non-XML RDF syntax, but almost nobody is using it; again, XML has the advantage of existing libraries and tools.

So my only remaining option was to design my own XML vocabulary. And I don’t think that’s a bad thing in this case. Tim’s arguments mostly involve designing a vocabulary for interchange between independently developed pieces of software. That’s not my situation. Other than current and future versions of Trifle, the only consumers of the format will be purpose-built scripts written by power users.

Besides, Trifle won’t ignore those common formats. I’ll include some form of Atom import and export, and probably HTML too. Maybe I’ll even do it by using XSLT to transform to and from Trifle’s format.