4 ms·

It's hard to believe this isn't just trolling. Writing a large app directly using SQL is not "hard," but A) it's exceptionally boring, B)it necessitates mental

It's hard to believe this isn't just trolling. Writing a large app directly using SQL is not "hard," but A) it's exceptionally boring, B)it necessitates mental context shifting from your app language to SQL, and C) it requires you to think about nuts and bolts routine below-your-paygrade solved concerns like SQL injection, transaction management, type casting, etc. Two more points: I've never seen a large app that either didn't use a popular ORM or didn't end up REINVENTING large chunks of functionality ORMs provide. Good developers write DRY code, and SQL everywhere leads to, eventually, some library that looks remarkably like... an ORM... Finally, in the case of large web applications (since that's HN's bread and butter), an ORM'd app will not need a "very substantial rearchitecting" to get rid of the ORM. That statement is patently absurd. Early in its life, for scaling (always, IF it becomes necessary) what it will need is dropping down to SQL to tune some aspects of some pages. Architect for doomsday if you like (or, conversely, if you need extra hours to bill) -- or architect to ship.

tieTYT 15y ago
There are libraries out there that already reinvent the large chunks of functionality ORMs provide without requiring you to use an actual ORM. I think the middle ground is the best way to go here. Avoid ORMs, avoid native SQL, meet somewhere in the middle.
- ryeguy 15y ago
  Like what?
  - rubashov 15y ago
    Perl has Fey. http://search.cpan.org/perldoc?Fey http://search.cpan.org/perldoc?Fey As ORMs go Fey::ORM (built on top of Fey) is good. It's easy to get under the hood and make it do exactly what you want. http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro
MartinCron 15y ago
A) it's exceptionally boring Perhaps as a result of it being so exceptionally boring that it's so error-prone. If you forget to wire something up by hand (especially if its nullable) and don't notice while you're coding, it can be one of those subtle little bugs that lingers in the background until it really bites you. Also, you forgot: D) Difficult and time-consuming to create test automation for.
- drivebyacct2 15y ago
  Yes! At least LINQ-to-SQL gives compile time type checking.
  - johnzabroski 15y ago
    Linq 2 SQL has ambiguous relationship path decision function when deciding how to map the Linq expression tree model to the SQL DBMS's model. Compile-time type checking is very illusory with heterogeneous execution, not only for this reason but also because it is a distributed application and the schema can change.
    - drivebyacct2 15y ago
      And I've been bitten by the truth of your statement. It sure beats the pants off writing SQL by hand.
  - keithnoizu 15y ago
    Is LINQ even in favor anymore. I think we're all about the entity framework now which appears to be more or less ORM with an auto update component for references to the orm objects.
    - drivebyacct2 15y ago
      No, but you still use LINQ style lambda expressions to do more advanced queries involving the EF objects. It's actually a really, really nice blend. If you're doing .NET dev though, take a look at NHibernate. It's been around longer, it's been stable much longer, it has more features... and it actually has a community which is probably EF's weakest point IMO.
epscylonb 15y ago
Good developers write DRY code, and SQL everywhere leads to, eventually, some library that looks remarkably like... an ORM... I agree with this. I think you can look at this two ways, over time you incur technical debt for a variety of reasons (if your app is being used or growing in any way). The articles author thinks it is best to start at the bottom and build up your "model layer" from scratch. People who use an ORM start from above and almost certainly will have to modify their entire software stack to address things like scaling and unusual features along the way. As long as you know your ORM well and can do the rearcitecting this really is not a problem. Basically whichever approach you take a good developer would end up with the app in roughly the same state. Personally I would prefer to start with an ORM and work down, just because it is a hell of lot quicker.
thorin 15y ago
You've never seen a large app that didn't use ORM? What about every large business application from the late 70s-early 2000s? A) I'm not sure why its execeptionally boring. Solving problems with sql is interesting and elegant in it's own way (like using recursion or functional programming to create an new algorithm). Lots of people posting who don't know so much about the specifics of the database the are using. Why spend thousands on Oracle or SqlServer then abstract all those features out? Phil

tieTYT 15y ago

There are libraries out there that already reinvent the large chunks of functionality ORMs provide without requiring you to use an actual ORM. I think the middle ground is the best way to go here. Avoid ORMs, avoid native SQL, meet somewhere in the middle.

ryeguy 15y ago
Like what?
- rubashov 15y ago
  Perl has Fey. http://search.cpan.org/perldoc?Fey http://search.cpan.org/perldoc?Fey As ORMs go Fey::ORM (built on top of Fey) is good. It's easy to get under the hood and make it do exactly what you want. http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro

MartinCron 15y ago

A) it's exceptionally boring Perhaps as a result of it being so exceptionally boring that it's so error-prone. If you forget to wire something up by hand (especially if its nullable) and don't notice while you're coding, it can be one of those subtle little bugs that lingers in the background until it really bites you. Also, you forgot: D) Difficult and time-consuming to create test automation for.

drivebyacct2 15y ago
Yes! At least LINQ-to-SQL gives compile time type checking.
- johnzabroski 15y ago
  Linq 2 SQL has ambiguous relationship path decision function when deciding how to map the Linq expression tree model to the SQL DBMS's model. Compile-time type checking is very illusory with heterogeneous execution, not only for this reason but also because it is a distributed application and the schema can change.
  - drivebyacct2 15y ago
    And I've been bitten by the truth of your statement. It sure beats the pants off writing SQL by hand.
- keithnoizu 15y ago
  Is LINQ even in favor anymore. I think we're all about the entity framework now which appears to be more or less ORM with an auto update component for references to the orm objects.
  - drivebyacct2 15y ago
    No, but you still use LINQ style lambda expressions to do more advanced queries involving the EF objects. It's actually a really, really nice blend. If you're doing .NET dev though, take a look at NHibernate. It's been around longer, it's been stable much longer, it has more features... and it actually has a community which is probably EF's weakest point IMO.

epscylonb 15y ago

Good developers write DRY code, and SQL everywhere leads to, eventually, some library that looks remarkably like... an ORM... I agree with this. I think you can look at this two ways, over time you incur technical debt for a variety of reasons (if your app is being used or growing in any way). The articles author thinks it is best to start at the bottom and build up your "model layer" from scratch. People who use an ORM start from above and almost certainly will have to modify their entire software stack to address things like scaling and unusual features along the way. As long as you know your ORM well and can do the rearcitecting this really is not a problem. Basically whichever approach you take a good developer would end up with the app in roughly the same state. Personally I would prefer to start with an ORM and work down, just because it is a hell of lot quicker.

thorin 15y ago

You've never seen a large app that didn't use ORM? What about every large business application from the late 70s-early 2000s? A) I'm not sure why its execeptionally boring. Solving problems with sql is interesting and elegant in it's own way (like using recursion or functional programming to create an new algorithm). Lots of people posting who don't know so much about the specifics of the database the are using. Why spend thousands on Oracle or SqlServer then abstract all those features out? Phil