[nzmsv]

A number of specialists in the field of databases got together and designed a DSL specifically for working with databases. It's actually a pretty good fit for its domain and is reasonably well designed. It's also pretty simple (it's even right in the name).

Then a bunch of non-specialists said "we don't want to use more than one language" and came up with some hacks to write DB queries in languages that were never designed for that. The hacky stuff actually ends up generating the proper query language behind the scenes, poorly.

One would wonder why would anyone prefer the hacks, but the appeal of using one language for everything is strong. This is also why DSLs never took off in general despite promising to significantly lower the cognitive load due to being a better fit for the problem domain. At least with most DSLs there are usually additional reasons not to use them: the implementation is usually not as good as the popular languages. This is not true for SQL, and yet is suffers from the same problem.

[kaba0]

So how do you “import” the results of those SQL statements into your general purpose application? Oh, so you need a mapping for that, let’s add some abstraction for that so we don’t have to repeat ourselves for each table and TADA, you’ve got yourself an ORM.

[anothernewdude]

I know quite a few languages, frameworks, what have you and if you can't see the benefits of not adding another damn thing for people to learn on to the pile, then I have no idea how you've missed a lesson that up to this point, it seemed every engineer I'd met has learned.

Not having to specify the mapping between business objects and a SQL database is massive value on it's own. Having not only the ability to avoid doing that, but upon making changes to your objects, being able to migrate the database easily is frankly amazing.

[nzmsv]

I guess we have met different subsets of engineers :)

I wish people were more open to learning more languages. A good DSL can be amazingly expressive. But you are correct in pointing out that gluing languages together is a pain, and it's a good reminder. Lesson learned ;)

[alephu5]

With an ORM you can leverage the IDE to get field names, types and descriptions by simply typing out the name of the model. In pure SQL you need to memorise the schema, or continuously switch contexts to refer back to it.

Another advantage is that you type-check your queries, whereas with pure SQL you can accidentally load a number into a string variable and crash the application.

Because of this I prefer very light ORMs that abstract almost nothing. Those that provide model definitions, automatic migrations and a one-one SQL mapping.

[nzmsv]

I guess it's all the standard trouble with DSLs: poor tooling integration, having to work at different layers.

An IDE that understood SQL would probably mitigate almost all opposition and yet nobody came up with one after all these years. So I guess the standard DSL defense doesn't really doesn't work.

All right, point taken, I'll take my downvotes and go home :) I don't use an IDE and most people I work with don't either. But this is a useful reminder that the world can be very different outside of one's bubble.

[chakkepolja]

> Because of this I prefer very light ORMs that abstract almost nothing. Those that provide model definitions, automatic migrations and a one-one SQL mapping.

Any particular recommendations? I tried hibernate in java and was put off by complexity.