4 ms·

>> but the core benefit is that the same code should work on multiple different hardware devices. I came here to say this. Attractions act as a bridge between

>> but the core benefit is that the same code should work on multiple different hardware devices. I came here to say this. Attractions act as a bridge between things which allow those things to change independently. Using an ORM allows my program to easily work against multiple sql databases. Using a compiler allows me to target different hardware. Using standard protocols allows me to communicate with different programs. Using libraries to do say email hides me from those protocols and allows me to adapt to service providers Using APIs not protocols. In other words the abstraction is designed to hide a layer (which can change) from a program not interested in that level of change. The key is to stop abstracting when the program cares. By all means encapsulate rules and processes, but they're a direct implementation of those rules and processes. One can argue my "calculateLeaveForEmployee" function is an "abstraction" - but that would be a misnomer. Since there's only one set of rules in play (the set that matters now) its an implementation. An abstraction supports (at least) two things at the same time.

necovek 2y ago
> Using an ORM allows my program to easily work against multiple sql databases. A curious example, since most developers who've worked on any project with significant amount of data in a database would likely disagree. IMO, ORMs mostly allow using programming-language-of-choice as a syntax for relational queries instead of constructing it by hand on top of serialization and deserialization of objects into rows and vice versa.
- ludston 2y ago
  Indeed, given that most sql dialects have subtle differences that make them noncompatible with one another, and most ORMs have support for dipping into raw sql, sufficiently large systems tend to end up coupled with a particular database anyway. That's not to mention that the BAs will want raw sql access for report writing and switching systems breaks all of their scripts too.
- zharknado 2y ago
  Yes, ORMs came to mind for me as an example of indirection without abstraction. If you accept OP’s litmus test of “how often do I have to peek under the hood” I think ORMs generally don’t score particularly well.
  - 9rx 2y ago
    If enabling the ablity to think of the database as the rich native data structures provided by the host programming language, and not the tables (rows and columns) that the underlying database service wants to think of the data as is not an abstraction, what is?
    - zharknado 2y ago
      Fair, it’s probably incorrect to say there’s “no abstraction” in an ORM, maybe more precise to say it’s quite a leaky one. I’ve never seen an ORM used in the wild where you could actually avoid thinking about tables and columns and rows pretty frequently. But that’s admittedly armchair anecdotal. In the small-to-medium scale cases I’ve seen, the main re-use you get for a particular mapping is when an object is used as a child node elsewhere. If it’s a one-off you’re essentially writing a bespoke shorthand wrapper for some custom SQL. Which may be a convenient shortcut or prettifier, but isn’t really functioning as an abstraction. Net net it seems like more overhead. Or like the real benefit is constraining database design to closely align with object design (which could be valuable but isn’t a function of abstraction). This is all assuming code ownership across the stack. With a separate team managing data representation and handing reliable object contracts “over the wall” I could imagine a situation where the consumer gets to think purely in objects. I just haven’t observed that in practice. E.g. What if the contact has two address records? What if the number of purchase records exceeds the maximum result size? If things like that come up regularly enough, it’s worse when you’re waiting on a separate team to fix the leaks.
      - 9rx 2y ago
        > I’ve never seen an ORM used in the wild where you could actually avoid thinking about tables and columns and rows pretty frequently. There is a compelling argument that absent the n+1 problem, it could be a leak-free abstraction. And, in practice, SQLite doesn't suffer from the n+1 problem... But that is definitely true in a lot of cases, particularly where the n+1 problem is unavoidable. > If it’s a one-off you’re essentially writing a bespoke shorthand wrapper for some custom SQL. While the original comment also conflated query building and ORM, I am not sure that we should. The intersection of query building and ORM was historically referred to as the active record pattern. I suspect the ActiveRecord library, from Rails, calling itself an ORM is where things started to become confused. Regardless, whatever you want to call the data mapping and query building, they are undeniably distinct operations. It may be fair to say that query builders are no more than an indirection. That said, I posit that they only exist as an abstraction to model composability on top of SQL. If SQL naturally composed through basic string concatenation, I expect the use of query builders would quickly disappear.
- mcfedr 2y ago
  It's interesting that some modern ORMs are dropping trying to abstract out the dB engine. Specifically thinking of Drizzle for js. And rather just focusing on the programming interface
javcasas 2y ago
> allows my program to easily work against multiple sql databases How many times have you required that your program runs against different sql databases without modification? I mean, how many times have you required your plane to be able to fly in the different atmospheres of different planets of the Solar System? Unless you are NASA, I suggest you cut the complexity and just make a plane that can fly well on Earth's atmosphere.
- bruce511 2y ago
  >> How many times have you required that your program runs against different sql databases without modification? Our main commercial product currently supports 2 database engines, and we'll be offering a 3rd next year. For enterprise offerings it's pretty common for the client to prefer, or outright specify, the engine. Commodotizing your complementary technology is a good way to not become dependent on any specific database, and hence can pivot quickly when required. Fortunately I don't have a plane, so I don't have code to fly in any atmosphere.
  - javcasas 2y ago
    Yes, yes, you are NASA. The rest of us go with Postgres, or SQL server, or Oracle, but definitely don't have to prepare our systems to run in PostgreSQL on Mondays, on SQL server on Tuesdays and so on.
  - Mawr 2y ago
    If the pivoting never happens then the effort will have been wasted. Adding features because of "what if" is the worst engineering sin.

necovek 2y ago

> Using an ORM allows my program to easily work against multiple sql databases. A curious example, since most developers who've worked on any project with significant amount of data in a database would likely disagree. IMO, ORMs mostly allow using programming-language-of-choice as a syntax for relational queries instead of constructing it by hand on top of serialization and deserialization of objects into rows and vice versa.

ludston 2y ago
Indeed, given that most sql dialects have subtle differences that make them noncompatible with one another, and most ORMs have support for dipping into raw sql, sufficiently large systems tend to end up coupled with a particular database anyway. That's not to mention that the BAs will want raw sql access for report writing and switching systems breaks all of their scripts too.
zharknado 2y ago
Yes, ORMs came to mind for me as an example of indirection without abstraction. If you accept OP’s litmus test of “how often do I have to peek under the hood” I think ORMs generally don’t score particularly well.
- 9rx 2y ago
  If enabling the ablity to think of the database as the rich native data structures provided by the host programming language, and not the tables (rows and columns) that the underlying database service wants to think of the data as is not an abstraction, what is?
  - zharknado 2y ago
    Fair, it’s probably incorrect to say there’s “no abstraction” in an ORM, maybe more precise to say it’s quite a leaky one. I’ve never seen an ORM used in the wild where you could actually avoid thinking about tables and columns and rows pretty frequently. But that’s admittedly armchair anecdotal. In the small-to-medium scale cases I’ve seen, the main re-use you get for a particular mapping is when an object is used as a child node elsewhere. If it’s a one-off you’re essentially writing a bespoke shorthand wrapper for some custom SQL. Which may be a convenient shortcut or prettifier, but isn’t really functioning as an abstraction. Net net it seems like more overhead. Or like the real benefit is constraining database design to closely align with object design (which could be valuable but isn’t a function of abstraction). This is all assuming code ownership across the stack. With a separate team managing data representation and handing reliable object contracts “over the wall” I could imagine a situation where the consumer gets to think purely in objects. I just haven’t observed that in practice. E.g. What if the contact has two address records? What if the number of purchase records exceeds the maximum result size? If things like that come up regularly enough, it’s worse when you’re waiting on a separate team to fix the leaks.
    - 9rx 2y ago
      > I’ve never seen an ORM used in the wild where you could actually avoid thinking about tables and columns and rows pretty frequently. There is a compelling argument that absent the n+1 problem, it could be a leak-free abstraction. And, in practice, SQLite doesn't suffer from the n+1 problem... But that is definitely true in a lot of cases, particularly where the n+1 problem is unavoidable. > If it’s a one-off you’re essentially writing a bespoke shorthand wrapper for some custom SQL. While the original comment also conflated query building and ORM, I am not sure that we should. The intersection of query building and ORM was historically referred to as the active record pattern. I suspect the ActiveRecord library, from Rails, calling itself an ORM is where things started to become confused. Regardless, whatever you want to call the data mapping and query building, they are undeniably distinct operations. It may be fair to say that query builders are no more than an indirection. That said, I posit that they only exist as an abstraction to model composability on top of SQL. If SQL naturally composed through basic string concatenation, I expect the use of query builders would quickly disappear.
mcfedr 2y ago
It's interesting that some modern ORMs are dropping trying to abstract out the dB engine. Specifically thinking of Drizzle for js. And rather just focusing on the programming interface

javcasas 2y ago

> allows my program to easily work against multiple sql databases How many times have you required that your program runs against different sql databases without modification? I mean, how many times have you required your plane to be able to fly in the different atmospheres of different planets of the Solar System? Unless you are NASA, I suggest you cut the complexity and just make a plane that can fly well on Earth's atmosphere.

bruce511 2y ago
>> How many times have you required that your program runs against different sql databases without modification? Our main commercial product currently supports 2 database engines, and we'll be offering a 3rd next year. For enterprise offerings it's pretty common for the client to prefer, or outright specify, the engine. Commodotizing your complementary technology is a good way to not become dependent on any specific database, and hence can pivot quickly when required. Fortunately I don't have a plane, so I don't have code to fly in any atmosphere.
- javcasas 2y ago
  Yes, yes, you are NASA. The rest of us go with Postgres, or SQL server, or Oracle, but definitely don't have to prepare our systems to run in PostgreSQL on Mondays, on SQL server on Tuesdays and so on.
- Mawr 2y ago
  If the pivoting never happens then the effort will have been wasted. Adding features because of "what if" is the worst engineering sin.