Anatomy of a Haskell-based Application | Hacker News Reader

Anatomy of a Haskell-based Application

abailly.github.io

92 pointsnicolast9 comments

I'm going to put it out there that this reflects badly on our community when we dislike RDBMS "just because."

When I tried to write a Haskell app, one thing I learned quickly was that most of the awesome Haskell features that are perfect for modeling a domain in Haskell were useless because the majority of my modeling needs to be done in the database and merely wrapped with Haskell, rather than written entirely in Haskell. That disappointed me a bit. But maybe I'm wrong, in fact I hope I was wrong!

I suppose it depends tremendously on the application you are developing but combining Haskell with things like Haxl[1] and opaleye-sot[2] can help simplify the database aspect of things tremendously.

Once you've abstracted away the persistence and querying details, I think you get to the best part of FP which is modeling the actual behaviour/flow of data and types. In a typical app lifecycle Haskell starts shining more as time goes on and the app grows past CRUD and in size.

[1] https://code.facebook.com/projects/854888367872565/haxl/ [2] http://ren.zone/articles/opaleye-sot

I've found the exact opposite to be true. With Postgresql, for example, strong types can be enforced through the entire application stack using tools like Opaleye. Check out composite types in Postgres and Opaleye to see what I'm talking about.

Some frameworks provide automatically generated type-safe entities, query, and update capabilites, such as the Yesod Persistent framework [0].

For a smaller but similarly safe approach, I reccomend Esqueleto.

[0] http://www.yesodweb.com/book/persistent [1] https://hackage.haskell.org/package/esqueleto

To be precise, Esqueleto isn't a smaller alternative, it's a layer on top of Persistent that gives you a typed DSL for SQL. It's been pretty nice when I used it, most things that I wanted to do in SQL were easily expressed. Exotic SQL functions that weren't available are easily imported in a type-safe way.

acid-state is a smaller, no-SQL alternative [1].

[1] https://hackage.haskell.org/package/acid-state

Thank you. I was thinking of Persistent as part of a Yesod Web framework and Esqueleto as something independent, which was not correct.

This is the case with many low-level libraries with Haskell bindings.

If you just wrap the C calls for some SQL database, or say, OpenGL, the resultant code ends up looking very imperative, stateful, and C-like.

Some people have tried to make more Haskell-ish wrappings with limited success.

Fortunately, even C-like Haskell is not totally awful. It's just not as nice as more idiomatic Haskell.

> the majority of my modeling needs to be done in the database and merely wrapped with Haskell

I highly recommend Opaleye for this (with the caveat that I'm the primary author!).

From the Opaleye front page:

> Opaleye is a Haskell library that provides an SQL-generating embedded domain specific language for targeting Postgres. You need Opaleye if you want to use Haskell to write typesafe and composable code to query a Postgres database.

> "Opaleye really is great. You've managed to bring what is so wonderful about relational databases and give it type safety and composition (i.e. what is wonderful about Haskell)" – Daniel Patterson, Position Development

https://github.com/tomjaguarpaw/haskell-opaleye/

Reply on news.ycombinator.com