8 ms·

I agree, and also think the tools we use shape us (and vice-versa). It may be a tradeoff between lower standards (e.g. "Can you use an ORM?") and steeper learn

I agree, and also think the tools we use shape us (and vice-versa). It may be a tradeoff between lower standards (e.g. "Can you use an ORM?") and steeper learning curve before someone can produce useful work. The former optimizes for more bodies that meet a certain criteria, the latter may optimize for a higher skill level on average. There are many other factors that contribute, but it's interesting to think about. (I know, for example, the Navy SEALs lowered their standards a ways back to increase enrollment... and some friends have said it's had a negative impact on the teams, because they have taken some people with behavioral profiles that would never have made it in the past. But they had more missions due to changing nature of warfare, and needed the numbers.)

nightski 8y ago
Maybe it's perception. I don't view ORM as a tool to make working with a database easier. In fact, it's harder to use but can have real advantages. For example, it would be nice to use raw SQL in our app but we have lots of reporting and data analysis functionality with support for custom grouping, filtering, etc... Composing queries on the fly with an ORM is trivial. On the other hand composing SQL strings or writing out manually the thousands of potential combinations would be very painful and brittle. I also find ORMs are great for transactional updates where you are only modifying a few entities at a time. They really reduce the amount of boilerplate required (reducing errors) and allow you to use refactoring tools (find usages, etc..) to locate where a particular column is used in the code base. So to me it's not about making SQL easier - because lets face it you have a complex translation layer there that requires full understanding. Rather it's about capturing those clear benefits.
- citrablue 8y ago
  The day-to-day is certainly up for debate -- I prefer SQL myself. But imagine the initial learning curve for someone fairly new to programming. Persisting data to, and reading data from, a "database" is a lot easier in code than learning SQL (which frequently use a client-server system, only further increasing the surface area of knowledge required to produce working results). The difficulty required to think about a solution increases significantly with additional components.
  - deleted 8y ago
    [deleted]

nightski 8y ago

Maybe it's perception. I don't view ORM as a tool to make working with a database easier. In fact, it's harder to use but can have real advantages. For example, it would be nice to use raw SQL in our app but we have lots of reporting and data analysis functionality with support for custom grouping, filtering, etc... Composing queries on the fly with an ORM is trivial. On the other hand composing SQL strings or writing out manually the thousands of potential combinations would be very painful and brittle. I also find ORMs are great for transactional updates where you are only modifying a few entities at a time. They really reduce the amount of boilerplate required (reducing errors) and allow you to use refactoring tools (find usages, etc..) to locate where a particular column is used in the code base. So to me it's not about making SQL easier - because lets face it you have a complex translation layer there that requires full understanding. Rather it's about capturing those clear benefits.

citrablue 8y ago
The day-to-day is certainly up for debate -- I prefer SQL myself. But imagine the initial learning curve for someone fairly new to programming. Persisting data to, and reading data from, a "database" is a lot easier in code than learning SQL (which frequently use a client-server system, only further increasing the surface area of knowledge required to produce working results). The difficulty required to think about a solution increases significantly with additional components.
- deleted 8y ago
  [deleted]