[zzzeek]

Until we've attained AI, all software can be said to be "stupid". Google is stupid. Relational databases are stupid, SQL is stupid. None of it works without human intelligence actively directing it to do work for us. Why single out ORMs?

[nolok]

That's called arguing for the sake of arguing ...

OP says one ORM is bad so all of them are, you say no some are nicely made (which I agree with), parent ask for a specific example you would recommend and you answer by nitpicking on a single word in his message, one that he even put in quotes himself. And then you finish with a question about something that parent didn't even say or infer.

Either you have an example and you provide it, or you don't and you say so, but your comment was unnecessary and unwanted.

(and so is mine, but I've seen so many of those on HN lately that I just broke and wrote that rant)

[zzzeek]

see my other comment to PommeDeTerre.

[lutusp]

> Until we've attained AI, all software can be said to be "stupid" ... None of it works without human intelligence actively directing it to do work for us.

You've implicitly defined AI as a level of intelligence that doesn't need human oversight to function. That level doesn't exist yet, but that doesn't mean AI doesn't exist -- it just has a different definition than the one you're using.

Consider Watson (the Jeopardy contest computer lately in the news) -- it can beat the best Jeopardy players, but it's completely unable to function if given a different task or deprived of human oversight. Notwithstanding that limitation, most people will claim it's an example of AI.

[InclinedPlane]

Software is a tool, ORMs are tools. I don't need a tool to do my work for me, I just need it to work well for whatever job it's for. A "stupid" hammer would be one that is just a rock with a hole in it loosely fitted over a stick that fits in the hole with nothing but friction to hold it on. A "stupid" farm tractor would be one that gets 15 mpg most of the time except when it's used during a full moon between 10am and noon, in which case it gets 1 mpg.

Most ORMs are indeed stupid. They often produce completely surprising results at the least opportune moments. They are high maintenance tools that require constant supervision to ensure that you haven't accidentally made some changes which causes something crazy to happen in the ORM. It's about the principle of least surprise, which ORMs often fail horrifically at.

[PommeDeTerre]

You're contradicting yourself. Your first comment indicates that it's wrong to label ORMs as "stupid". Yet in this latest comment, you've labeled all software (which includes ORMs, of course) as "stupid".

Like the other commenter requested, can you provide an example of an ORM that isn't "stupid"? Your initial comment makes it sound like you've worked with at least one that isn't. We're curious to learn about which these may be.

[zzzeek]

The word "stupid" here is ambiguous, so can be interpreted as, "stupid", "it's stupid to use them" (I disagree), or "stupid", "they don't necessarily understand your intent" (this applies to all software), "stupid", "simple issues are made more complicated than they should be, to an unreasonable extent" (this is a problem that varies to a significant degree based on the ORM in use and cannot be generalized based on the experience of just one ORM). Without the benefit of the speaker's words here it's hard to tell, though the only backing evidence given in these slides for "ORMs are stupid" is a trivial issue that not every ORM has, so that's IMO not a good argument.

View my profile for further detail.

[white_devil]

The problem with ORMs seems to be that they're a leaky abstraction. I've been very happy using SQLAlchemy for quite a while now, but I'm intentionally only using the SQL Expression API. Based on my experience with Hibernate, there's always something you want to accomplish that necessitates circumventing your ORM.

Not only that, but typically you end up balancing between stuff being unavailable because of lazy-loading, and one pageview taking 30 seconds because the ORM collected all the dependencies.

[zzzeek]

> The problem with ORMs seems to be that they're a leaky abstraction.

I disagree it's a problem.

going back to Joel again (!) :

"All non-trivial abstractions, to some degree, are leaky."

I talk about this a lot in this particular talk: https://www.youtube.com/watch?v=E09qigk_hnY

Hibernate was a great influence on me but I like to think that it only introduced some ideas in rough form that we've all had many years to improve upon.

The ORM will of course introduce new issues to deal with but this is because it's taking care of a vast amount of persistence code you no longer have to write, and applies a consistency to that persistence logic that would be extremely difficult to achieve without using tools.

[white_devil]

Look, I'm willing to believe that SQLAlchemy is the bad-assest ORM on the planet, but I'm not convinced I'll never need to circumvent it to get something done, and I'm free to consider that a problem (along with other commenters, it seems).

As I mentioned, I'm very happy using SQLAlchemy's lower level API. It's a helpful and elegant abstraction over queries and table definitions etc, and I've never needed to circumvent it yet. I'm also convinced that the delightfully flexible/powerful Mako is hands down the best templating library for Python. You, sir, Rock. But you come off as needlessly argumentative in this thread.

[zzzeek]

sorry, I did a whole talk inspired by the term "leaky abstraction" and thought it was relevant.

[PommeDeTerre]

You know, you could've just directly mentioned SQLAlchemy earlier...

[zzzeek]

I don't like making my posts look like plugs for my own stuff, though I guess it's unavoidable....

[espeed]

In these type of discussions, it's not a plug -- it provides examples and evidence useful for teaching, which can light a path to a better way.

As Abelson and Sussman point out in SICP, "Computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute" (http://mitpress.mit.edu/sicp/front/node3.html).

The software we write is a codified expression of what we think, distilled into a working example that can elevate a discussion from theoretical-based to evidenced-based. Those who have devoted time to think through an issue deeply and have codified their thinking into software would be doing a disservice by not referencing it.