You should take a look at the ORMs that are considered a bit more at the top of their class. In the Python world SQL Alchemy in the Ruby world Sequel. While you can't judge all ORMs by looking at a few these do offer a better impression of what an ORM can do for you.
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?
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)
> 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.
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.
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.
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.
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.
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.
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.
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.
That don't try to handle hidden-magic-state and lets you easily access via Raw SQL if you need to do complex queries. Many don't try to abstract anything and are simply extension methods over the underlying IDbConnection (so you never lose any flexibility), i.e. they simply exist to remove the tedium boilerplate of mapping RDBMS results back into POCOs.