On 14 December 2014 at 18:52, Manuel Gómez
Congratulations on the release! It’s great to see more and more interesting abstractions for relational databases in the Haskell ecosystem.
Hi * I chime in for the first time. Haskell is my favourite language. I really don't program in it, I have done it very little. I like more reading about Haskell (et al). What I really do, is work with geo(yay) data(yay)BaseManagementSystems(meh) and SQL(yuck). Yes, despite SQLs yuckiness I feel myself most naturally among NATURAL JOIN and other relationally algebraic friends. I'm very sorry, but I had a strong gut reaction to Manuels sentiment. Really?! What's so great about it? Isn't this rather a sign that something is askew? For such an important, ubiquitous yet mundane task as accessing database there shouldn't be so many ad hoc half-baked (sorry - with some limitations) solutions. That's unfair, I know. I look at those examples and think, this is not the Haskell I'd like to write and despite type safety and composability, which are great features, it's not even the query language I'd like to write. Ie it's not better than SQL, yet. I mean, I understand the need to talk to SQL DMBS-s. I guess I'm just sad and angry that the great talent of library authors is wasted on such endeavor. Of course no Haskell programmer wants to write SQL, because the L is so askew in SQL. (apologies to Hugh Darwen). BUT, but. If Haskell hasn't got tuples as in relations (named, not ordered), type system such that tuple types' arity is not fixed (if that's the correct way to put it) and types for sets of such tuples aka relation type, then how can Haskell support databases and relational algebra NATURALLY? On the other hand, if Haskell had those, it would be quite a relational language, right? And a GREAT one, no? Anyway, bye! Riivo