Hacker News Reader

Comment by misterbowfinger | Hacker News Reader

Ah yes - the proverbial "ORMs are bad, just learn SQL" post. This is analogous to saying "don't use frameworks". Sound ridiculous? Yes, yes it is.

The law of leaky abstractions applies to many, many things, ORMs included. I would also argue they apply in different degrees, usually related to the design of the ORM (the post mentions SQLAlchemy vs. Hibernate, for example).

But consider the following:

1) Why do people still use ORMs? Exactly.

2) Question 1 but s/ORM/framework_or_widely-used-library

3) ORMs allow you to develop faster, and deliver value

4) Beginners already have a hard time coding, designing, and understanding what they're doing. ORMs provide a nice abstraction over underlying data stores

5) Although fraught with peril, ORMs provide a common interface that'd give _some_ help if you switch data stores

6) Multi-line SQL statements are a huge pain in some languages

View on HN

In response to (4). I'd posit that beginners have a hard time with this stuff because they use too many leaky abstractions. Like the article says, if you want to use an ORM for anything non-trivial, you need to learn both the ORM and SQL, which is inherently more difficult than just learning SQL.

Providing tons of abstractions to beginners so they can build something in 10 lines of code doesn't help them get better. All it does is encourage them to learn top-down when it's often much easier to learn something from the bottom-up.

> This is analogous to saying "don't use frameworks". Sound ridiculous? Yes, yes it is.

When developing API's in Golang or for microservice / serverless architectures not using a framework might actually make a lot of sense. Also microframeworks (trimmed-down versions compared to opinionated frameworks) are very popular in almost any language.

There are such things as micro-ORM as well, btw. Still an ORM though.

I'd say that Golang rather comes with a (simple) framework in the standard library, so you don't need a third-party one. After all, http.Handle/HandleFunc clearly follow the Hollywood Principle: http://wiki.c2.com/?HollywoodPrinciple

ORMs are bad, because objects aren't particularly useful to deal with most data.

And when you've already been through the effort to make your data relational for the database, might as well re-use that effort.

That's not to say that SQL is the answer. Proper first class support for relations in your programming language / libraries is great.

As for using a DSL, Datalog is worth a look.

> ORMs are bad, because objects aren't particularly useful to deal with most data.

Objects are containers of data; that's a crazy statement to make. The relational structure maps pretty cleanly to objects, properties, and collections.

However, objects are not good for reporting. And the author mentioned doing 14 joins and hundreds of columns - that smells like a reporting query.

The relational structure maps cleanly to badly designed objects, where most classes have 5-10 fields and most fields are opaque data values with setters and getters. If you wrote classes like that in isolation, you'd have to do some serious work in code review, explaining why a hodgepodge collection of properties is a single unit of responsibility. But I've never worked in an ORM-using system where they weren't endemic.

I don't buy into the idea that those kind of classes are just unqualified bad design. The majority of applications exist to merely to store information entered by users. Using a class to hold that data in a structured and type-checked way is perfectly reasonable.

And they aren't a hodgepodge collection of properties; they're entities that represent a single item in a system whether that be a person, a widget, an order, or a product.

> The relational structure maps cleanly to badly designed objects

If you are exposing base tables to the application instead of appropriate views, which as much a violation of good RDBMS design principles as what you describe is a violation of good OO design.

But why do you need these containers of data, when you could have more direct access to both the data itself and the whole set (not individual objects, nor collections of objects)

I dont like ORMs but did struggle some years trying to use them which imho was a detour. SQL and stored procedures in plpgsql is so much better, easier to maintain, easier to reason about etc.

How would you calculate the average of the sum of three columns (AVG(A + B + C)) which are chosen by the user at runtime?

I personally would write a simple plpgsql stored procedure, but I would not trust user input and only allow a defined set of colums from a defined set of tables.

you can have lots of dynamic sql but that might become a rabbithole, just as with an ORM. It sounds like a problem you shouldnt have, now throwing an ORM at such a problem... might lead to even more strange issues down the road...

I personally would write a simple plpgsql stored procedure, but I would not trust user input and only allow a defined set of colums from a defined set of tables.

Sure, you can limit it to a single table and to a certain set of columns e.g. A B C D E. Can you give me an example of a simple plpgsql stored procedure to do this?

you can have lots of dynamic sql but that might become a rabbithole, just as with an ORM

That's not my experience. In a language with good introspection and/or where most entities are first-class, you can do this rather easily. In Python that would take two or three short lines.

It sounds like a problem you shouldnt have

This is a bit of a cop-out :) allowing the generation of simple reports configured by the user is a typical need for us.

By this logic, no bad practices exist.

Reply on news.ycombinator.com