6 ms·

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 (

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 13y ago
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.
- PommeDeTerre 13y ago
  You know, you could've just directly mentioned SQLAlchemy earlier...
  - zzzeek 13y ago
    I don't like making my posts look like plugs for my own stuff, though I guess it's unavoidable....
    - espeed 13y ago
      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 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.
- white_devil 13y ago
  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 13y ago
    > 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 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 13y ago
      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 13y ago
        sorry, I did a whole talk inspired by the term "leaky abstraction" and thought it was relevant.

zzzeek 13y ago

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.

PommeDeTerre 13y ago
You know, you could've just directly mentioned SQLAlchemy earlier...
- zzzeek 13y ago
  I don't like making my posts look like plugs for my own stuff, though I guess it's unavoidable....
  - espeed 13y ago
    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 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.
white_devil 13y ago
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 13y ago
  > 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 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 13y ago
    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 13y ago
      sorry, I did a whole talk inspired by the term "leaky abstraction" and thought it was relevant.