Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.
tfw when constraints are longer than the function body image.png
this is the dream
each of those constraints is writing code for you :)
I'm not a friend of beam, but tbh, those constraints tell me more about what the function does than the implementation
@Mats Rauhala why do you not like Beam? what do you prefer?
I would just go with postgres simple.
Instead, I endorse writing a simple function with a clean type and writing some tests for it.
addPerson :: WithDB r m => Person -> m ()
Of course, when your purpose is to learn something new or have fun, go with what you want
ok, I have only used Hasql so far, I guess that comes with a similar cost
Yeah, hasql is nicer than PG simple in my eyes. Not abusing typeclasses for encoding / decoding stuff makes it pretty excellent and painless to deal with. :heart:
yes, that's a positive aspect I also noticed when perusing the Beam docs.
I've been playing around with deriving Row and Params for my types, which works pretty fine, but it's a bit tedious that I can't (afaict) simply run those codecs for testing
my experience with codecs has often been that it's undesirable when the data type has to incorporate stuff for derivation in its fields, like the Columnar in Beam
though I still use generics-sop, so that's kind of similar, only more general
though looking at my code now I realize that the most significant parts of the derivations deal with the constructions of statements, the codecs are rather trivial
You know, hasql is not something I've ever really tried. IIRC you still write raw sql queries on it, but define the encoders/decoders with functors / contravariant functors instead of typeclasses. So I would liken it with postgresql-simple. The full power of SQL with the type safety of haskell where it matters the most.
Personally I haven't had any pain with having type classes as encoders (like psql, aeson, quickcheck), but I've seen plenty of people having pain with it