I Don't Want to Teach My Garbage DSL, Either

As a single non-representative example, ActiveRecord has `before_insert` hooks you can simply add as methods to your model class. Ecto doesn't have those.

com·plex·i·ty n. the state or quality of being intricate or complicated.

I think, invariably when you use ORM, you end up having query-specific object structures. For example [1].

You also might be passed objects with deferred fields [2]. This will be completely opaque to someone consuming the resulting object. You'll eventually run into this problem [3]. Solving the lazy load problem requires an understanding of how SQL works in the first place. And if you look at the solution in that example, it's an ORM-wrapped series of joins.

From 3: > For good measure, we add a raiseload to throw an exception if we try to load anything that we didn’t load here.

Who wants to live in this world?

1: https://stackoverflow.com/a/45905714/5573538 2: https://docs.sqlalchemy.org/en/13/orm/loading_columns.html#c... 3: https://engineering.shopspring.com/speed-up-with-eager-loadi...

> Data Mapper: A layer of Mappers (473) that moves data between objects and a database...

(https://martinfowler.com/eaaCatalog/dataMapper.html)

Sounds like an ORM to me.

Some people try to distinguish between the "data mapper" pattern and the "active record" pattern (it's not just the name of the Rails library, it's a pattern... which the Rails library may or may not implement very well). Both are ORMs, because both are ways of mapping from an rdbms to an object system.

(Neither of which actually has to do with query DSL. We could imagine just taking the part of ActiveRecord that produces queries, but having it return simple hash/string literals. It wouldn't really be an "ORM" (except in the most technical sense that even hashes are objects in ruby), but it would still have the parts you don't like. The nature of query building is actually not related to 'data mapper' vs 'active record' -- you could have an instance of either in which you wrote raw SQL queries, or an instance of either which used the same non-SQL DSL)).

But even distinguishing between "data mapper" and "active record", in actual practice, I don't think there are two completely separate, distinct, and unified camps. I don't think these categories actually serve well to deliniate the ORMs we've got. Instead, there are a just a whole bunch of approaches, some more light weight than others, some more mature/reliable than others, some 'leakier' than others, differing on all sorts of additional dimensions. I agree that some ORMs are better than others -- and some may disagree on which these are -- I don't think saying "data mapper" is actually useful for understanding which these are.

There are lots of weird parallels between SQL and Smalltalk. For example, both SQL and Smalltalk are constructed with Douglas Hofstader's "strange loops." All Smalltalk object instances have a class, and the classes themselves are object instances. SQL tables are defined using metadata stored in SQL tables. Another parallel, is that the language variants are very similar, but ultimately incompatible to the point where translation is non-trivial. In Smalltalk, this is due to a toothless language standard, resulting from political maneuvering by various language vendors. Not sure what it is in the case of SQL.

There is a problematic relationship between DSLs and libraries in languages of sufficient power. In programming languages with a certain level of expressive power, it's easy to write a DSL on top of a library, or on top of another DSL.

https://xkcd.com/927/

I used to joke about "lady/gentleman computer scientists." What's the difference? A computer scientist knows how to implement another computer language. A lady/gentleman computer scientist knows when they should know better.

A DSL should be used to super-charge your project's very idiosyncratic special context. The trick is knowing better when you shouldn't. Accessing a database isn't your project's very idiosyncratic special context.