Hackfoofery

Alson Kemp

Turbinado is “not nearly as innovative”

From Happstack:

“[If HApps doesn't do anything...] the project will eventually be superceded by other Haskell frameworks like Turbinado which are not nearly as innovative”

Woohoo!  People are talking about Turbinado!

err… Wait! Turbinado is being dissed!

Turbinado vs. HApps

Each project is valid and valuable, so I’m hesitant to get to far into a X vs. Y discussion, but here are some aspects that I thought about when evaluating HApps and developing Turbinado:

  • Turbinado is built on top of Nicklas Broberg‘s HSP/HSPR, which I consider to be an innovative-port of ASP to Haskell…
  • HApps is a much bigger project with many more features; Turbinado is small and needs your help [shameless plug: help here].
  • HApps seems more like a library of really useful functions which is very flexible; Turbinado is more like a web app framework and provides a web server along with defined mechanisms for adding Controller, Views and ComponentsConvention over Configuration = different styles, not better styles.
  • HApps seems less than simple (see here); Turbinado is all about simple (see here)
  • HApps has an aversion to relational databases; Turbinado observes that lots of people use relational databases and supports them.

Turbinado vs. HApps, again

To me, it seems as though the choice between HApps and Turbinado depends more on orientation than on functionality.  If you are interested in: opposing RDMBSs, but are into something like Sinatra, then HApps is probably the best choice; if you’re interested in writing web apps in the style of Ruby On Rails, then Turbinado (though young and pretty) may be the best choice, especially given the simplicity of building Turbinado (newly cabal installable!  to be described in a forthcoming post with tutorials, install details, singing, dancing, high kicks, etc).

Here’s To Success

Most successful languages have more than one web framework, so I hope for success for both HApps and for Turbinado. They’re very different frameworks and serve very different needs. The Haskell community would be well served if both frameworks survived and thrived.  As Merb and Rails have demonstrated, cross-pollination is excellent; the stronger HApps and Turbinado are, the more they can benefit each other.

Written by alson

February 3rd, 2009 at 2:28 pm

Posted in Haskell,Turbinado

with 26 comments

26 Responses to 'Turbinado is “not nearly as innovative”'

Subscribe to comments with RSS or TrackBack to 'Turbinado is “not nearly as innovative”'.

  1. As Merb and Rails have demonstrated, cross-pollination is excellent; the stronger HApps and Turbinado are, the more they can benefit each other. –> I agree.

    Matthew Elder

    3 Feb 09 at 2:40 pm

  2. How does Turbinado compare to WASH? I really like that you can write your web app as if it’s a real app (rather than the “one app per page” style), and the marshalling of data from one page to the next is handled internally. I also like that it runs over CGI (shared hosting is cheap).

    Sebastian

    3 Feb 09 at 5:22 pm

  3. Sebastian,

    I’m not completely sure how Turbinado compares to WASH (http://www.informatik.uni-freiburg.de/~thiemann/WASH/). It’s been a while since I checked WASH out… WASH seems to have died, though, since the last update was 2 years ago. WASH also reminded me a bit of ASP-style development where there’s little guidance. I’m a fan of Rails’ layout and syntax, so wanted to replicate that more closely than ASP-style systems.

    I’ll check out the marshalling of data from one page to the next. That’s something I’ve been wrestling with in Turbinado.

    -A

    alson

    3 Feb 09 at 5:39 pm

  4. It would be cool if Turbinado supported the same “log” based session protocol so you could run a site as purely CGI (as I understand it, the site just sends a log of the actions taken so far back to the server each time). Of course, like WASH, there would still be the option of running it as a server (avoiding the cost of reconstructing the session from the log) or both (speed and robustness! Perhaps by storing the log as a cookie so the server could request it by need). See the Wash Server Pages section of the WASH site.

    Sebastian

    3 Feb 09 at 5:46 pm

  5. Well said. I love the idea of being able to use haskell with some existing (relational) databases and I’m thrilled to see some work being done toward supporting HAML.

    Jason Dew

    3 Feb 09 at 8:57 pm

  6. Jason,

    HAML’s been pretty hard to write a parser for… mostly because I’m not strong on writing parsers… The code is in Turbinado/View/HAML/trhaml.hs if you want to take a gander…

    With Turbinado moved on to GHC 6.10, I’m heading back to fleshing out the framework, so look for serious progress over the next few weeks.

    A

    alson

    3 Feb 09 at 9:04 pm

  7. Alson, how integrated is the ORM into Turbinado ?

    Can i use it without being forced to use ORM ?or is it like Railsprety much revolves around it ?

    Can i use plain sql with HDBC instead ?

    Vagif Verdi

    4 Feb 09 at 3:20 am

  8. Hi!

    Probably not so developed as HApps and Turbinado, but there is another framework coming along called Yesod (see http://blog.snoyman.com/2009/01/31/first-real-yesod-commit/) which is supposed to work even on cheap shared hosting.

    Sincerely, Gour

    Gour

    4 Feb 09 at 8:09 am

  9. Vagif,

    The ORM is not at all integrated: it’s just a bunch of generated helpers for you to use your database. Turbinado’s ORM is loosely modeled on .netTiers, so you’re free to use the ORM generator or free to not use it. It’s very easy to use HDBC within the Controllers (liftIO; instance MonadIO Controller) (I’m going to also add HDBC convenience functions in to the Controllers so that you shouldn’t have to use liftIO in the near future). Thanks for the comment; I’ll make sure to add your note to the Database discussion on the Turbinado website.

    Gour,

    Thanks for the pointer to Yesod. Looks interesting. I am working right now on addressing some of Yesod’s strength (authentication; response types). Excellent to see another framework in process. Finally, Haskell is getting some love!

    Turbinado should work fine in a shared hosting environment. Naturally, GHC would have to be installed locally (so that dynamic compilation would work) and the shared host would have to provide mod_proxy-like functionality (since Turbinado is a light HTTP server).

    alson

    4 Feb 09 at 12:26 pm

  10. Hi!

    Nice you like some parts of Yesod…

    Excellent to see another framework in process. Finally, Haskell is getting some love!

    Let’s hope there will be, at least, one complete web Haskell framework (excluding HApps) out of all this attempts :-D

    Turbinado should work fine in a shared hosting environment. Naturally, GHC would have to be installed locally (so that dynamic compilation would work) and the shared host would have to provide mod_proxy-like functionality (since Turbinado is a light HTTP server).

    Hmm, is the above really shared-hosting-friendly?

    Gour

    4 Feb 09 at 3:23 pm

  11. Most shared hosting plans don’t allow you to have any persistent processes though – you’d need to support a CGI version. Ideally you would build two versions at once so you could use CGI for testing and small apps, and scale to a full server if you’re successful and can afford something more expensive.

    Sebastian

    4 Feb 09 at 3:55 pm

  12. Gour, Sebastian,

    doh. Sorry, I was thinking of VPSs and not shared hosts. The big, big, big problem with running Turbinado in a shared env (aside from the CGI bit) is that Turbinado dynamically compiles, loads and caches Controllers and Views. The first compile and load can be pretty slow (similar to ASPX files) and a shared environment would incur that penalty on every page since every page would be a new start of the process…

    alson

    4 Feb 09 at 7:05 pm

  13. Could it not cache the .o files on disk? Or even write out an baked executable that it just redirects to immediately if it’s not out of date?

    Sebastian

    4 Feb 09 at 7:28 pm

  14. Not that a solution for shared hosting is mandatory, but I’d estimate that the vast majority of people who would use a brand new web framework would be enthusiasts who’d just stick it on whatever server they get for free at school or whatever (or something like nearlyfreespeech.net, which is what I’m using for some pet projects, with WASH/CGI, incidentally).

    You kind of need those people to build hype, IMO, so it would be good if Turbinado didn’t just cater to the 1% who has access to a dedicated server or can afford to blow significant chunks of change on a VPS solution.

    Sebastian

    4 Feb 09 at 7:35 pm

  15. Sebastian,

    Turbinado does write cached .o files out to tmp/compiled, but it’d probably take a while for the RTS to load in the files on each startup. There might be a way to provide an option to build all of the various Controllers, Views, etc into Turbinado statically, but I hadn’t thought too much about that. Might be a useful thing to do for ‘production’ versus ‘development’ environments. I’ll noodle on that. At first thought, it sounds pretty difficult to do given the architecture of Turbinado…

    alson

    4 Feb 09 at 8:14 pm

  16. I think that we’re still searching for a web framework that has the right amount of Haskell-iness, whatever that really means, and it’s great to see people working on different experiments (HAppS, Turbinado, etc.).

    I’ve been (quietly) watching your work on HAML with some interest.

    And, why is this blog hosted on WordPress?!? Dogfood!

    Paul Brown

    5 Feb 09 at 1:59 am

  17. Heh, it means I was right that Turbinado is, similar to HApps, not meant for shared-hosting (aka: masses).

    Well, that’s OK and it leaves us with the hope that Yesod will make it.

    I can get a ‘shared’ hosting for Django for 4€/m, and it would be great to have Django-like framework for hacking in Haskell. :-)

    Gour

    5 Feb 09 at 2:48 am

  18. Gour,

    VPSs can be had for around $20/m (about twice as much as a shared host), so for a bit more you gain a ton of flexibility (for Django, too).

    Paul,

    Yes, the blog is on WordPress, because Turbinado wasn’t mature enough to build a blog on. It will be mature enough in a few weeks time, though I’m not sure a blog would be my initial target…

    On HAML, I’ve been putting a bit of time into it here and there. The biggest problem I have is that I need to figure out how to support XML and HAML simultaneously. That’s occupying the majority of my time. I think that I’ll wind up modifying the “trhsx” translator to handle HAML… and that frightens me…

    Also, could you tell me more about what is the right amount of Haskell-iness? I think I kinda feel the same way. With Turbinado, I’m trying to provide all that really helpful stuff from Rails without crushing the Haskell-iness, but I’m not sure that I’m hitting the mark…

    alson

    5 Feb 09 at 11:57 am

  19. A shared host can be had for a few cents per month, if you use a plan that bills you for usage only (like nearlyfreespeech.net) and you don’t use much bandwidth/storage.

    I’m not writing comercial web apps, I just want to use Haskell to write some basic crap for me and some friends – $10 a month would be more than I would be prepared to pay for something like that. In comparison I’ve had my nfs site for about a year now, and I’ve only paid $5 so far.

    Anyway, the point is that the cheapest VPS is two orders of magnitude more expensive than the cheapest shared hosting, so if you truly want a web app for the masses, it needs to work on shared hosting.

    Sebastian

    5 Feb 09 at 2:24 pm

  20. Sebastian,

    To be fair, the only things that work on shared hosting in that scheme are PHP, Perl, etc. — straight CGI. You can get that from Haskell with the CGI libraries.

    Rails and its ilk are not suitable for bare bones shared hosting because of their resource requirements.

    Paul Brown

    5 Feb 09 at 6:35 pm

  21. Alson,

    The place where I have trouble thinking about the right kind of Haskell-iness is in producing HTML or other output. Achieving something like the “provides” of Merb is where we should aim, and it’s probably a good application for Haskell’s type system.

    Paul Brown

    5 Feb 09 at 6:52 pm

  22. Alson,

    I wouldn’t be offended at someone saying Turbinado is “not nearly as innovative.” I think Happs is too innovative, in the sense that it needlessly reinvents wheels. Relational databases are pretty well established at this point, and I think building on top of them is a Good Thing.

    Also, thank you for taking a look at some of my ideas on Yesod. As others here have said, I think you should reconsider the decision to not build in support for CGI. Sure, dynamic recompilation is nice, but to me it sounds like a great development feature, whereas a fully compiled CGI executable sounds like a reasonable deployment version.

    Providing those two alternate paths, I believe, would be the best of both worlds: the kind of rapid development hitherto known only to the unwashed masses of scripting languages ;), along with the power of Haskell.

    Definitely let me know if you have a change of heart on this topic, you’ll at least gain a lot more interest from me. In fact, I’d probably drop my framework attempt and join yours, since I otherwise like your approaches.

    Michael

    Michael Snoyman

    6 Feb 09 at 2:43 am

  23. Paul,

    Thanks for the pointer on Merb “provides”. I’ve been trying to figure out how to do something similar with Turbinado. My inclination is to find automatically the proper View. So Abba/Ding -> Views/Abba/Ding.hs, Abba/Ding.xml -> Views/Abba/Ding.xml.hs, etc. Probably clearLayout if a format is specified… Would that be a good solution?

    Michael,

    Dynamic recompilation isn’t only a dev feature. Or I assume that it isn’t since Rails and ASP.NET both provide for dynamic recompilation in production settings. That said, like ASP.NET, Turbinado can be darned slow to start up.

    The biggest issue I see with going to static Controller/Views is figuring out Cs/Vs exist at compile-time. Seems as though the most straightforward way to do this is to create a StaticDispatcher and a DynamicDispatcher. If Config/App.hs says to use the StaticDispatcher, then your StaticRoutes.hs will be used to build the CodeStore.

    This actually might not be so difficult. At startup, a addStaticRoutes filter could be run to build a CodeStore from Config/StaticRoutes.hs; at runtime, the CodeStore could check the DynamicDispatch flag to determine whether it should look around for Cs/Vs or just use what’s in the CodeStore. If you have more than 10-15 Cs/Vs (or Components), this route could get really painful…

    I’ve just finished up Cookies and want to do CookieSessions (for authentication) then. That’ll comprise V0.5. I’ll ping you thereafter to see if you’re really game to contribute to Turbinado if I add a StaticDispatch option. ;)

    alson

    6 Feb 09 at 1:17 pm

  24. Alson, Michael,

    it would be great if you join the forces to make one complete Haskel web framework for ‘unwashed masses of scripting languages’ :-D

    All the best, Gour

    Gour

    10 Feb 09 at 3:30 am

  25. Gour,

    I’ve already started stealing Michael’s code (a hideous reword of some of his lovely code is here), so I just need to get StaticRoutes done. Then I’ll plead the case to Michael. ;)

    alson

    10 Feb 09 at 2:30 pm

  26. Alson,

    great to hear it.

    I’m really looking forward to see new release with (hopefully) some more docs/tutorial_apps to start playing with Turbinado hoping to fullfill my web needs in Haskell instead of going to Django.

    As it was mentioned in the comment(s) above, I like Turbinado’s “not nearly as innovative”-ness and I’m sure with (more) support for shared-hosting it can become reall killer-app with fast-growing community…

    All the best!

    Sincerely, Gour

    Gour

    11 Feb 09 at 3:14 am

Leave a Reply