You make it sound like your options are "use the crippled abstraction layer" or "use the full-powered database layer." You're leaving out two very important points:
1. There's a reason the abstraction layer exists: it can be clumsy to go directly to the full-powered database for simple stuff. 2. You can bypass the abstraction layer whenever you want. I like to describe Persistent's goal as doing 95% of what you need, and getting out of your way for the other 5%. You can write raw SQL queries with Persistent. I use this for implementing full-text search. I haven't needed to write deep analytical tools recently, but if I did, I would use raw SQL for that too. Persistent's advantage over going directly to the database is concise, type-safe code. Are you really telling me that `runSql "SELECT * FROM foo where id=?" [someId]` plus a bunch of marshal code is better then `get someId`? Michael On Mon, Feb 13, 2012 at 9:53 PM, Paul R <paul.r...@gmail.com> wrote: > I have quiet a lot of experience in the business of web services > strongly backed by data stores, in a company that allowed me to apply > a technologies such as RubyOnRails, DataMapper, PostgreSQL, Redis, Riak, > HappStack and Snap. Greg, with no offense intended, I will share with > the café a conclusion that we took year to draw, but that made out job > much better since : Abstraction over high level data stores is one of > the worst idea in software engineering. > > The most proeminent example is probably PostgreSQL, which is an > incredibly strong product with high SQL power. But as soon as you access > it through the ActiveRecord or Persistent API, it gets turned into > a very limited store, with the SQL power of SQLITE or MongoDB. > > So Sergiu, my POV is that universal data stores is at best a glue > targeting small projects, so that they can be hacked quickly. They offer > a set of features that, by design, is the greatest common divisor of the > backends, which unfortunately isn't that great. This is certainly nice > for a do-a-blog-in-5-minutes with "MyFramework init" video tutorial, but > probably not for industrial projects in the long run. > > As a side note, the acid-state package that Greg kindly mentioned, takes > a very different approach to data storage, resulting in > a haskell-centric solution with an original features set. > > Regarding your other option, the value behind the LLVM backend seems > huge for the whole Haskell community. It has the power to lighten GHC, > improve runtime performance, bring binaries to more platforms and much > more. In my opinion, that's quiet exciting :) > > > Greg> Hi Sergiu, > Greg> Thanks you for your interest in that proposal. I rushed it off a year > Greg> ago. Since then we have made a lot of improvements to Persistent and > Greg> the library forms a basic building block for most Yesod users and > Greg> other Haskellers. Persistent offers a level of type-safety and > Greg> convenience not available elsewhere (except perhaps for libraries like > Greg> acid-state that are limited to in-memory storage). That being said, > Greg> there are still a lot of improvements that could be made. With the > Greg> effort of a GSoC volunteer we could probably get it to the point of > Greg> being the go-to data storage library for Haskellers, at least those > Greg> planning on using the subset of backends (likely SQL) with great > Greg> support. This proposal is vague and we would need to work with you to > Greg> narrow things down a bit. > > Greg> I am biased, but I believe the Yesod project is one of the most > Greg> compelling in the Haskell ecosystem. There are a lot of different ways > Greg> a GSoC project could help make things even better besides improving > Greg> the associated Persistent library, and we would really like to mentor > Greg> at least one GSoC student. I would open more tickets for this in the > Greg> system, but I am not sure how helpful it will be. It seems that we > Greg> need to reach out to more students like yourself, but I am not sure > Greg> how to do that unless I see messages like these first. > > Greg> Greg Weber > > -- > Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe