One of my crazy plans for total obscurity (the inverse of world domination) is to try bringing some of the back cover benefits of functional languages to the web frameworks arena, basically to build a Rails or a Django in Haskell.

Well, first of all I’ve never used Rails, so I suck. So I downloaded it. Haven’t done anything with it yet, but just to get it on disk is a big step (I’m on the Django devs mailing list for gawd’s sake, though only as a lurker). It’s all in the name of research guys, honest.

More than anything, this is an exercise in learning a language by applying it to a familiar domain. However, the advantages of implementing such a platform with Haskell are:

1. Non-strict evaluation and compilation provide greater efficiency. Data structure documentation with efficiency comments in big O notation can’t hurt either :-).
2. Expressiveness and clarity of code, Ruby is a touch Perlish, though all the Rails examples are fairly pretty (this is DHH’s stated goal for Rails after all). Django isn’t quite so pretty perhaps, focusing more on practicality. Python and Ruby have some neat syntactic toys, but Haskell is the state of the art when it comes to expressive code.
3. Strongly-typed but with type inference. One of the great things about Django (and possibly Rails) and a feature I prized in InfoCMS was beautiful joyous harmony between the types used at the data layer and the types used at the interface layer. Forms are validated using information about the tables the data will have to later be injected into. Lots of very sturdy data types would be fantastically useful for this.
4. Removal of side effects. Side effects should be limited to the supporting layers that interact with the DB or with the OS etc, my code should be purely functional, allowing clarity and easier debugging and testing.

Now, I’m reading from the Haskell crib-sheet a bit here, and I haven’t necessarily felt the power of these supposed advantages just yet, but it’s all interesting theory.

On the other hand, there are some clear disadvantages compared to the way things are done in Django and Python at least, and I suspect Rails and Ruby too.

1. Haskell is a compiled, static language. Django’s ORM for example, does all kinds of runtime dynamic magic to provide a slick programmer experience. Though they’re removing the more magical magic, introspection is still a big part of the toolset. Particularly in the realm of data models and mapping, it will be hard to provide something as usable under compilation.
2. No objects, no variables even! My functional skills are not so leet. I’ve always been an OO boy. Learning to live without objects and side effects would not be impossible, but it’s a huge paradigm shift for me and probably everybody else. Most web hackers want to make their lives easier, and while learning Ruby is a jump many have demonstrated their willingness to make, a whole new language paradigm is a much larger one.
3. Development speed. The great debate: strong typing, prevents bugs or just slows coders down? Everyone has to unit test anyway, so just catch ‘em there. Now strong typing in Haskell is certainly no where near as much as a drag as in Java or C++ for instance, type inference whilst retaining both parametric and ad hoc polymorphism means a lot. However I’m certain that the code-compile-test loop sucks compared to edit-test. The compile step is a big drag on my hacking style, and GHC is not known for it’s speediness in compilation. I remember hacking Java for wwWebflow and zoning out completely through compiles, so much so that I’d get really lazy and stupid when the time to edit and test came again. This could probably be solved by building a test environment which uses GHCi or Hugs in interactive mode. This would be a must really.

Discussion with Ladislav on Hypothetical centered around the problems of implementing the ORM layer without the O bit. Thinking about that now, I think the best way to go would be to allow a developer to specify rules for marshaling Haskell record types into tables (Django’s doing this here). A good set of defaults would be provided, but allowing tweaking of the marshaling rules would allow tenacious DBAs to squeeze maximum performance from the application . Rules would ideally be written in Haskell allowing insertion of custom bits like index magic. Code for pulling records from the DB would be functional, the prevailing model would probably be to write query functions that get used by the controllers. It would be nice to have a Django/Rails/Class::DBI style interface, I just have to think about that some more.

Some of the concerns are deal breakers, but I’d love to test them in the wild. Haskell apps have tended to be toys a bit so far, with the notable exception of Darcs. I guess I kind of hope that there’s some possibility that a Haskell web framework could garner some interest in the same way. I should just stick to Django probably :-).

I did actually write some actual code on Sunday, for what it’s worth. Just some types for representing requests and responses really, all of which is already done in HWS. It felt good though.