meh, i have used anorm. their site jabs at ORMs and jabs at Slick (typesafe SQL dsl in scala); but the wording of both jabs make it clear that they've missed the point of both tools. Slick is not about types - its about adding one-off functions to remove all the repition from complex SQL - and ORM isn't about hiding SQL under the hood, it's about expressing very complex queries at a higher level than is possible in SQL. Just because someone wrote it on the internet does not make it so.
If your app is simple CRUD on 10 tables, anorm is great. But even for CRUD on complex types (nested objects, objects with collections of objects, objects with values that aren't primitives e.g. dictionary types where possible values aren't known until runtime...) those queries will be crazy complex and repetitive in raw SQL and you will quickly see you need an orm (or move off sql to some other acid alternative like datomic). Anorm would be an ideal layer to write your own ORM in though.
That seems totally backwards. If your app is a simple CRUD app, then ORMs save you time. For complex apps, ORMs generally can't even express what you want, or can only do so in incredibly inefficient ways, so you end up dropping down to SQL anyways.
"ORMs generally can't even express what you want, or can only do so in incredibly inefficient ways, so you end up dropping down to SQL anyways"
on the project/team i work on, this statement is false. If it's true for some other team, maybe they are "doing it wrong". I'm sure it depends on one's particular ORM implementation, and whether it is any good, and what it's design goals are.
What ORM are you using? I've never seen or heard of one that people didn't have to drop down to sql with (or a pseudo SQL language that is converted directly to SQL).
a custom one actually, and it does have tons of warts and i'd rather be using datomic, but it does an exceptional job of expressing high level queries that expand into a mess of nested SQL expressions.
I used to be of this train of thought. It took a long while and a few different options. I'm now of the opinion that it's like everything else I encounter, sometimes it has a place.
I don't like the large ORMs, at all, though. I've used a few Micros (C#) and settled into PetaPoco for a few tasks which are CRUD heavy to allow internal users to maintain some data and it has saved me a lot of time.
I can write the hell out of some SQL, but sometimes I don't need to be doing it, it's just dead simple stuff. There can be concerns for people currently unfamiliar with SQL which I understand.
Yes, but that is exactly the point GP was making: ORM's are a DSL for automatically generating CRUD-type applications, that happen to be a passable language for accessing relational databases. Meanwhile, SQL is a DSL for accessing relational databases, but it takes more work to make CRUD-type applications. Hence, there are use cases for both.
Imagine how slow progress would be if for every different condition you had to either create a new query or alter an old one, with the latter potentially meaning you have to add new JOINs, adding weight to all other queries based off that string. It's very painful - I should know, this was my reality for a few months before implementing an ORM over the top.
If you want to abstract part of a common query, then do so. That is what views are for. Everyone trying to sell the world on ORMs always seems to make this mistake. You can't say "if you do things the worst possible way now, an ORM can help you!" and expect me to be excited. I don't do things the worst possible way, I already get the benefits you mention from my database.
I think the Anorm developers say this best: "SQL is already the best DSL for accessing relational databases. We don’t need to invent something new." http://www.playframework.com/documentation/2.1.1/ScalaAnorm