A Trifle Absurd

Choosing Haskell Was a Mistake

I’m going to drop Haskell as Trifle’s development language and go back to plain ol’ Objective-C. I still love Haskell the language, but I have to reluctantly admit that it just doesn’t make sense in this context.

Trifle will be a user-interaction-focused app. Most of the code will be directly interacting with or extending Cocoa objects. If I did that in Haskell, it would amount to writing Objective-C code with Haskell syntax. And even the stuff that was independent of Cocoa, like document data and rules, would still have to be structured to interact with the GUI code somehow. I’d spend way too much time working on crossing the chasm between Haskell and Objective-C.

Moving to Objective-C has its advantages, too. I can use XCode and its associated tools for debugging, profiling, and leak detection. I can easily generate universal binaries, rather than cobbling something together by hand. I’ll have a smaller executable with fewer dependencies. I can take advantage of Objective-C-entwined stuff like Cocoa Bindings.

I have mixed feelings about this switch. I’m bummed to set Haskell aside; it’s a great language, and fascinating to program in. I’m also sorry to give up garbage collection. But I’m convinced I gain more than I lose, in this situation. The way forward looks much clearer, and I’m reenergized to jump into Trifle anew.

Cocoa Bindings and Haskell

I’m wondering if Cocoa Bindings are any use to me as a Haskell developer. The whole point of Bindings is to take data from a preexisting Objective-C object and display it in a view, with appropriate syncing in both directions. But if I’m using Haskell data structures to begin with, I’d have to add an extra layer to sync the data with an Objective-C object for Bindings to connect to.

Wouldn’t I be better off eliminating that extra layer, and just implementing my own NSTableDataSource (or whatever) that knows how to interact with Haskell data? Or is there an advantage in having an NSArray in the middle for Bindings and Haskell to interact through? I suppose there are hybrid approaches: I could implement an object that supports the NSArray interface for Bindings’ sake, but actually is all Haskell underneath.

Dabble DB

Avi Bryant (of Seaside fame) and Andrew Catton are developing Dabble DB, a lightweight database that runs over the web. They have some enticing example screenshots and a screencast.

Dabble looks like a very cool app: applying the usability lessons of spreadsheets to the database arena. I could say more, but Avi and Andrew have already said it better on their Smallthought blog.

I see Dabble as another instance of what Ted Goranson called “a new breed of desktop applications, a breed in which there is no king—no winner by having the most features. In this new generation, different philosophical approaches to organizing information are pursued by different developers. […] Diversity of cleverness will reign.” He was speaking in the context of outliners, but his point resonates beyond outliners to other sorts of organizing applications, like Dabble and (someday soon) Trifle.

New Site Design

I’ve revamped the site design, changing the theme and adding standalone project pages for Trifle and Overleaf. Both of those just contain brief explanatory blurbs for now, but I hope to add more information as time goes on. I’ve also created a new about page.

The new theme is an adapted version of the Pool theme by Borja Fernandez. I changed the color scheme, removed a few images, and made various other tweaks.

A big hat tip to Lorelle VanFossen for cluing me in to the Firefox Web Developer Extension, which made those theme changes easy. Live CSS editing is a wonderful thing.

A Tale of Three Models

I’ve found a way to frame my search for a fundamental Trifle data model, by looking at the Finder, Lotus Agenda, and outliners.

The classic Finder model includes three kinds of things: folders, files, and attributes. None of these are interchangeable, though the modern Finder blurs the lines a bit.

Lotus Agenda unifies folders and attributes into categories. Assigning an item (i.e. file) to a category can be seen as giving it an attribute, or as putting it into a folder.

Most outliners unify folders and files into headers. Any header can have its own content (like a file), and can have children (like a folder).

I suppose Trifle could combine them all into one kind of thing—an item—which can look like a folder, a file, or an attribute, depending on your viewpoint. It would be pretty easy to implement, but the question is whether it would make sense from a user’s perspective. After some bad experiences using Everything-Is-An-X platforms, I’m naturally a little leery of the grand unified model.