A Trifle Absurd

More Haskell, More Fun

The more I get into Haskell, the more I like it. It seems that every Haskell program I write turns out shorter and simpler than I expected — a happy consequence of functional-programming power married to a clean and simple syntax. I said I probably wouldn’t use Haskell for production code; now I’m seriously rethinking that. My saner self reminds me, though, that I should wait ’till the new-language-infatuation phase has passed before deciding.

As I continue to learn about Haskell’s distinctive features, I’ve found a couple of helpful papers: Philip Wadler’s The Essence Of Functional Programming is a clear explanation of what monads are and what they’re good for; John Hughes’s Why Functional Programming Matters demonstrates the practical utility of lazy evaluation for real-world cases like alpha-beta minimaxing.

Giving Haskell A Try

I’ve had the impression that Haskell is a language designed by theoreticians for theoreticians, and thus unlikely to be interesting to little ol’ practical me. The feeling that Haskell is “like ML, only more so” has been a big turnoff, considering my dislike of ML (see this post). The famous indecipherability of monads didn’t help either.

You can see where this is going: the Surprising But Inevitable Reversal. Now that I’ve tried Haskell, I actually like it! It’s elegantly concise, with a well-designed syntax that I like a lot more than ML’s. It has the best static type system I’ve seen, hands down (ML isn’t even close). And I think I’m even beginning to understand monads.

I can tell I’m still not thinking in lazy-evaluation terms, though. The code I’ve been writing is more or less what I’d write in any functional language. Perhaps I should scout around for a tutorial of useful lazy idioms — the standard examples like the infinite list of primes don’t really generalize to everyday programming.

I doubt I’ll end up writing production code in Haskell (though who knows?), but it’s a fun and interesting language that expands my conception of programming — to me that’s reason enough to give it a whirl.

Maybe I Want to Reinvent the Wheel

I’ve said for a while that I want Trifle to be just a thin glue layer and UI on top of preexisting components that do the heavy lifting. This makes logical sense, since Trifle is a one-man project and I’d like to get it up and running in a reasonable amount of time. I’m starting to wonder, though, if that approach is shooting my enthusiasm in the foot.

Sure, I could squeeze my organizing schemes into a relational-database mold and thereby have less code to write, but then all I have to write is largely-uninteresting SQL-munging stuff. On the other hand, if I build my own database, I get to write the fun parts. (I recently had a blast implementing Patricia trees in Scheme.) I could even take a hybrid approach: use Berkeley DB as the low-level storage engine and design my own indexing and querying schemes on top of it.

I’ve resisted ideas like that, thinking that it would be quicker and easier to build upon a higher-level component, but now I realize that’s not necessarily true. If I leach out the joy by covering all the fun parts with existing code, I won’t be motivated to actually work on it, and so “quicker and easier” will become “slower and drudgier”.

Components: Relational Databases

One other obvious document-repository possibility for Trifle would be a relational database. Having never delved into that world in school or on the job, I took some time last year to educate myself on SQL and database stuff in general. The more I learned, though, the more it seemed that a relational database was a poor fit for Trifle.

I’m revisiting that ground, now, though. Having a solid database backend means there’s a whole lot of code I don’t have to write. Not only that, but many databases have their own fulltext-indexing capabilities, so I wouldn’t have to worry about yet another component to do that.

So if a database on the back end handled organizing and searching, the only major remaining piece would be versioning. The versioning needn’t be complicated, either. I don’t really need most of the features of a VCS like Subversion, so maybe I could roll my own versioning approach into my database design. A relational database might make sense after all.