On Jun 28, 2011 9:16 AM, "Greg Weber" <greg@gregweber.info> wrote:
> I would much rather revisit this issue in a month or so than keep this
> thread alive, but I feel the need to defend the good name of Yesod.
> Yesod libraries are no more complex than other Haskell libraries.

I'm not sure where we have different definitions in mind; surely it can't be controversial that web application containers are far more complex than most other libraries.  Just look at the dependencies on any such project.  I'd call it a fair statement that no one thought the problems of Cabal scaling to very large numbers of packages was much of a problem until web frameworks started being a big deal.  It also seems rather non-controversial to point out that Yesod includes a lot more here than other options; the Snap project, for example, happily proclaims itself to work at a level of abstraction analogous to servlets, and currently makes no attempt at solving persistence, form handling, and such.

In any case, sorry if that sounded like sullying the "good name" of Yesod.  I didn't even think it was particularly controversial.

> The issue is simply that a Yesod thread assumes you have developed a web
> application in Yesod. Or if it is about implementation, it may assume you have
> looked at a library's internals. As you said, it isn't about your lack of *general* web
> development knowledge. It is a lack of Yesod *specific* knowledge.

Yes, that's precisely my point.  I can think of very few other domains of Haskell programming where having not used a specific library even if you're familiar with the kind of problem it solves causes discussion about that library to look about as meaningful as ancient heiroglyphics.  OpenGL would be one, as well as GHC internals.  I'm having trouble finding other examples.

Again, this isn't a dig at Yesod... I don't think *anyone* has found a good way to build a web application framework that's both simple and obvious to understand and solves the hard problems.  I think it's at least partly endemic to the problem domain.

--
Chris Smith