undefined | Better HN

0 pointsjoaodlf2y ago0 comments

> I swear the majority of these opinion posts against ORMs are from people who must have worked in a badly implemented project that left them with a bad experience and they blamed the pattern rather than the technology.

Fair. But you then proceed to detail a personal experience on the other side of the spectrum: Badly written code, without an ORM, and how it was fixed by introducing an ORM.

I think we can all agree that you can write bad code, with or without an ORM :). Not that this is entirely relevant to my post, I am simply advocating for writing more SQL, not how to write a good object mapper. That's a different beast, and I purposely kept that simple just to illustrate that it is possible to get started without too much pain.

0 comments

dagmx2y ago

My point with the personal anecdote is precisely that you can write bad or good code with both. however that an ORM can allow for more consistent experience across many more people.

My point is different than your takeaway. In my point I’m not blaming the technology, I’m blaming the people involved with using it in production.

I specifically point out that a well versed engineer can write a SQL based system well. An ORM just means I can diffuse that responsibility over multiple people more reliably.

lelanthran2y ago

> My point with the personal anecdote is precisely that you can write bad or good code with both. however that an ORM can allow for more consistent experience across many more people.

I find it interesting that you say that; my takes is that it's the other way around!

SQL join statements look the same no matter what programming language the reader is used to, but each ORM differs in the way the join looks to the reader. The EF method of filtering your results set in C# looks very different indeed to how the ORM for Python would do it.

Every ORM looks different, which results in a very inconsistent experience for people, especially when you bring in a DB expert to figure out why there's a slowdown somewhere, and he cannot just visually inspect the EF/SQLAlchemy code and say "Well, here's what's wrong".

DB experts can usually very easily do that just by looking at the SQL, no matter what programming language was used.

dagmx2y ago

DB experts tend to be the minority though. It’s about indexing (pun intended) on the expert experience vs the generalist experience.

Often those may be very competing goals , where nativeness to the primary language used by the team might be more important than the nativeness of the expert.

aidos2y ago

To be fair, in sqlalchemy you could just do “print(query)” and you’d see your sql.

1 more reply

aforwardslash2y ago

> Badly written code, without an ORM, and how it was fixed by introducing an ORM.

Funny how those anecdotal bits never get published, eh? Its always "I shaved my db requirements in half by actually understanding what was going on because my orm is magic". Odd, innit?

j / k navigate · click thread line to collapse

0 pointsjoaodlf2y ago0 comments

Fair. But you then proceed to detail a personal experience on the other side of the spectrum: Badly written code, without an ORM, and how it was fixed by introducing an ORM.

0 comments

dagmx2y ago

My point with the personal anecdote is precisely that you can write bad or good code with both. however that an ORM can allow for more consistent experience across many more people.

My point is different than your takeaway. In my point I’m not blaming the technology, I’m blaming the people involved with using it in production.

I specifically point out that a well versed engineer can write a SQL based system well. An ORM just means I can diffuse that responsibility over multiple people more reliably.

lelanthran2y ago

> My point with the personal anecdote is precisely that you can write bad or good code with both. however that an ORM can allow for more consistent experience across many more people.

I find it interesting that you say that; my takes is that it's the other way around!

DB experts can usually very easily do that just by looking at the SQL, no matter what programming language was used.

dagmx2y ago

DB experts tend to be the minority though. It’s about indexing (pun intended) on the expert experience vs the generalist experience.

Often those may be very competing goals , where nativeness to the primary language used by the team might be more important than the nativeness of the expert.

aidos2y ago

To be fair, in sqlalchemy you could just do “print(query)” and you’d see your sql.

1 more reply

aforwardslash2y ago

> Badly written code, without an ORM, and how it was fixed by introducing an ORM.

Funny how those anecdotal bits never get published, eh? Its always "I shaved my db requirements in half by actually understanding what was going on because my orm is magic". Odd, innit?

j / k navigate · click thread line to collapse