>There was a heavy implication that they market at the expense of engineer.
I am impressed at your ability to read that which I did not write. There was no such implication, it is a criticism of happstack and snap. More talking = more users = more feedback = better framework. It is especially unfortunate that snap originally seemed to be making serious efforts at marketing, and then just sort of stopped.
>Fair enough. We try to stick to the "dumb storage system" model because it gives us a lot of flexibility and makes scaling easier
We avoid the dumb storage model because it eliminates flexibility, and forces us to re-implement database functionality in our app code. We're talking about starting from scratch, I just don't want to start by throwing away all the power of our database for nothing. Our biggest apps are only in the 10s of millions of rows range, so scaling isn't a problem. If it were, I'd be looking into actual dumb storage systems though (mongo, cassandra, etc) instead of using an RDBMS as a slower version of one.
>But remember, Persistent != Yesod. You'll notice yesod-core doesn't depend on persistent at all.
Yes, but as I said that is the big feature that yesod appears to provide vs happstack and snap. But upon closer inspection we had to go down to hdbc regardless of the framework.
>[[citation needed]] I think the principle difference is that Yesod plays to Haskell's strengths in being "radically typesafe"
Citation for what? That if you don't use persistent then yesod and happstack and snap are similar in functionality? I am not sure how to prove that, how about the other way? What other functionality does yesod offer that I am forgetting?
Yesod avoids haskell in attempting to be "radically typesafe". You get the exact same amount of type safety by using blaze-html and web-routes in happstack or snap as you do using yesod. As I mentioned before, yesod's template haskell, quasi-quotation fetish is rather controversial in haskell land. You can get the benefits yesod offers while retaining composability and the familiarity of using haskell instead learning a DSL. The amount of errors we see in compiled haskell code is minimal, it should not be shocking that this extends to yesod.
I am impressed at your ability to read that which I did not write. There was no such implication, it is a criticism of happstack and snap. More talking = more users = more feedback = better framework. It is especially unfortunate that snap originally seemed to be making serious efforts at marketing, and then just sort of stopped.
>Fair enough. We try to stick to the "dumb storage system" model because it gives us a lot of flexibility and makes scaling easier
We avoid the dumb storage model because it eliminates flexibility, and forces us to re-implement database functionality in our app code. We're talking about starting from scratch, I just don't want to start by throwing away all the power of our database for nothing. Our biggest apps are only in the 10s of millions of rows range, so scaling isn't a problem. If it were, I'd be looking into actual dumb storage systems though (mongo, cassandra, etc) instead of using an RDBMS as a slower version of one.
>But remember, Persistent != Yesod. You'll notice yesod-core doesn't depend on persistent at all.
Yes, but as I said that is the big feature that yesod appears to provide vs happstack and snap. But upon closer inspection we had to go down to hdbc regardless of the framework.
>[[citation needed]] I think the principle difference is that Yesod plays to Haskell's strengths in being "radically typesafe"
Citation for what? That if you don't use persistent then yesod and happstack and snap are similar in functionality? I am not sure how to prove that, how about the other way? What other functionality does yesod offer that I am forgetting?
Yesod avoids haskell in attempting to be "radically typesafe". You get the exact same amount of type safety by using blaze-html and web-routes in happstack or snap as you do using yesod. As I mentioned before, yesod's template haskell, quasi-quotation fetish is rather controversial in haskell land. You can get the benefits yesod offers while retaining composability and the familiarity of using haskell instead learning a DSL. The amount of errors we see in compiled haskell code is minimal, it should not be shocking that this extends to yesod.