4 ms·

> If I can hold ten items in my brain's working memory and all ten are taken up by keeping track of how many levels deep I'm in... If you find yourself doing t

by jt2190 10y ago

> If I can hold ten items in my brain's working memory and all ten are taken up by keeping track of how many levels deep I'm in... If you find yourself doing this, it is a clear indication that the software design is failing to abstract properly or at all. (I'd argue that the industry in general has a terrible ratio of "coders" to people who can design programs, thus you're much more likey to come across poor designs than good ones. Beware of this when judging programming languages.)

qznc 10y ago
> a clear indication that the software design is failing to abstract properly or at all I believe, it is an indication that people tried to fix all the leaks in the abstractions, which turns the abstraction into an ugly twin of the stuff it tried to simplify. ORMs are a good example. They start easy and simple, but lack various features of full SQL. If you start a new project, the ORM is fine. At some point, you are forced to use plain SQL, which clashes horribly with the ORM concepts. Thus the desire to extend the ORM. Over time more and more features are bolted on and the complexity grows.
- Consultant32452 10y ago
  IMO that's still bad design on the end user of the ORM library. There's a time and place to use tools like Hibernate, but it became fashionable so it's used all over the place where it doesn't fit and has created huge messes. There's a really bad trend in the industry of choosing libraries or tools based on trying to improve your resume, rather than trying to find the best solution to a problem.
  - willtim 10y ago
    Absolutely, just look at all the Hadoop users who don't really have big data.
  - cryptonector 10y ago
    I've worked with a number of ORMs, mostly home-grown, admittedly. I've yet to see a good one. Often ORMs fail to implement JOINs efficiently. Every ORM fails to give you a powerful query language: if they had a powerful query language, someone would write an ORM for the ORM, because the reason ORMs exist is that "SQL is hard", as the doll says, and any powerful query language will get the same treatment. But SQL is not really hard, and not having SQL eventually means you pay a huge price. And then there's things like LDAP, which are absolutely awful. LDAP's object naming scheme has no canonical text representation. Let that sink in. And that's not even the main problem -- forcing your database to be hierarchical and a collection of objects, with no standard relation/pointer type, is. (Yes, Active Directory has an Object DN type, I'm aware.) Just say NO to ORMs.
    - greenleafjacob 10y ago
      This is a well known issue [1], and isn't due to ORMs being poorly written. It's not true that people who know SQL always prefer using it to using an ORM. In one of my prior jobs we had strict controls on the queries that ran in production for performance reasons. We screened all of the query plans the planner generated, but we also used an ORM. Sometimes we needed to work around or even reimplement the queries that used to be in SQL due to niche features like index hinting or the HAVING clause. And yet usually we used the ORM because it was more concise and reduced manual mapping of columns to fields. [1]: https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch https://en.wikipedia.org/wiki/Object-relational_impedance_mi...

by jt2190 10y ago

qznc 10y ago

> a clear indication that the software design is failing to abstract properly or at all I believe, it is an indication that people tried to fix all the leaks in the abstractions, which turns the abstraction into an ugly twin of the stuff it tried to simplify. ORMs are a good example. They start easy and simple, but lack various features of full SQL. If you start a new project, the ORM is fine. At some point, you are forced to use plain SQL, which clashes horribly with the ORM concepts. Thus the desire to extend the ORM. Over time more and more features are bolted on and the complexity grows.

Consultant32452 10y ago
IMO that's still bad design on the end user of the ORM library. There's a time and place to use tools like Hibernate, but it became fashionable so it's used all over the place where it doesn't fit and has created huge messes. There's a really bad trend in the industry of choosing libraries or tools based on trying to improve your resume, rather than trying to find the best solution to a problem.
- willtim 10y ago
  Absolutely, just look at all the Hadoop users who don't really have big data.
- cryptonector 10y ago
  I've worked with a number of ORMs, mostly home-grown, admittedly. I've yet to see a good one. Often ORMs fail to implement JOINs efficiently. Every ORM fails to give you a powerful query language: if they had a powerful query language, someone would write an ORM for the ORM, because the reason ORMs exist is that "SQL is hard", as the doll says, and any powerful query language will get the same treatment. But SQL is not really hard, and not having SQL eventually means you pay a huge price. And then there's things like LDAP, which are absolutely awful. LDAP's object naming scheme has no canonical text representation. Let that sink in. And that's not even the main problem -- forcing your database to be hierarchical and a collection of objects, with no standard relation/pointer type, is. (Yes, Active Directory has an Object DN type, I'm aware.) Just say NO to ORMs.
  - greenleafjacob 10y ago
    This is a well known issue [1], and isn't due to ORMs being poorly written. It's not true that people who know SQL always prefer using it to using an ORM. In one of my prior jobs we had strict controls on the queries that ran in production for performance reasons. We screened all of the query plans the planner generated, but we also used an ORM. Sometimes we needed to work around or even reimplement the queries that used to be in SQL due to niche features like index hinting or the HAVING clause. And yet usually we used the ORM because it was more concise and reduced manual mapping of columns to fields. [1]: https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch https://en.wikipedia.org/wiki/Object-relational_impedance_mi...