4 ms·

Some abstractions are basically perfect and don't require you to understand the layer beneath them at all. Some have that as their ideal, but are imperfect, and

Some abstractions are basically perfect and don't require you to understand the layer beneath them at all. Some have that as their ideal, but are imperfect, and sometimes require you to understand a few details of the layer below. But others - the best example that I know of is SCSS - aren't even trying to eliminate the need to understand the layer below. Everything you need to know to write CSS, you still need to know to write SCSS, and then SCSS adds more on top. It's a convenient tool for power users and I wouldn't want to be without it, but for a beginner, using SCSS instead of CSS means you have strictly more to learn; I'd suggest that a newbie on my team not touch SCSS until they've done a few days' work with raw CSS. While less clear-cut than SCSS/CSS, it seems to me that ORMs/SQL have a similar relationship. Frankly, without knowing SQL, you can't hope to competently use an ORM; you won't know what sort of queries and updates it's capable of or what its performance characteristics will be, let alone more subtle stuff like what indexes to create or how the database's transaction model works. But even once you DO understand the SQL layer, getting to grips with how ORMs work is a major additional hurdle. For that reason, while I am comfortable using an ORM for projects I work on, I wouldn't recommend that a beginner do the same. If I did, I'd be doubling the amount they have to learn, and creating a risk that they'll give up in despair trying to figure out how something poorly-documented works at the ORM layer because they don't have the knowledge of the underlying SQL layer to intuitively guess what their ORM code must be doing under the hood. It's perhaps more radical than anything I believe, but I think you can reasonably go further and make the case that the extra learning curve imposed by ORMs is not worth the minor convenience benefit they offer to the proficient, and that for that reason, it's generally better not to use them. The fact that they leak the entire layer underneath them is part of that argument, but not all of it; the other part is that the layer they build on top of that is difficult-to-learn and only adds a small bit of convenience in exchange.

BigJono 7y ago
Some abstractions don't seem to give anything useful at all other than homogeneity across code bases and slightly nicer looking (but not simpler) code, and yet they still see wide use.
- ryanbrunner 7y ago
  If "nicer looking" aids readability and more understanding of what the domain logic is trying to achieve, that's a pretty substantial win in my book. One advantage of homogeneity is that it allows you to not have to think as much about how something was implemented, and focus on why that code exists and what it's trying to accomplish at a high level.
- stcredzero 7y ago
  Some abstractions don't seem to give anything useful at all other than homogeneity across code bases and slightly nicer looking (but not simpler) code This is of tremendous value to big companies. This lets them move to newer languages and platforms more easily when the time comes.
  - BigJono 7y ago
    For sure. It's also very good for onboarding (and better utilising cheaper/less knoweledgeable devs by constraining them, but people don't like to admit that). The flip side is that abstractions (usually in the form of external dependencies) can only add complexity to the software, which has a detrimental effect on development effort. These "pointless" (but not really) dependencies we're talking about are the same as useful ones, but instead of weighing the cost against a more direct benefit (whatever the library gives), you're weighing it against these more indirect benefits, which is much harder. In my experience most people just give up and go with whatever sounds good, which is usually "use whatever people are familiar with". That subset of tools grows and grows over time, and if you just always go with the defaults, eventually you're going to end up stuck in the mud, because nobody is weighing the cost of your abstractions.
    - stcredzero 7y ago
      These "pointless" (but not really) dependencies we're talking about are the same as useful ones, but instead of weighing the cost against a more direct benefit (whatever the library gives), you're weighing it against these more indirect benefits, which is much harder. Facades and the various "layer" style abstractions aren't pointless. The whole point is to add a layer of indirection, for the benefit of being able to switch out underlying dependencies. The whole point is to make it easy to migrate off of a dependency.

BigJono 7y ago

Some abstractions don't seem to give anything useful at all other than homogeneity across code bases and slightly nicer looking (but not simpler) code, and yet they still see wide use.

ryanbrunner 7y ago
If "nicer looking" aids readability and more understanding of what the domain logic is trying to achieve, that's a pretty substantial win in my book. One advantage of homogeneity is that it allows you to not have to think as much about how something was implemented, and focus on why that code exists and what it's trying to accomplish at a high level.
stcredzero 7y ago
Some abstractions don't seem to give anything useful at all other than homogeneity across code bases and slightly nicer looking (but not simpler) code This is of tremendous value to big companies. This lets them move to newer languages and platforms more easily when the time comes.
- BigJono 7y ago
  For sure. It's also very good for onboarding (and better utilising cheaper/less knoweledgeable devs by constraining them, but people don't like to admit that). The flip side is that abstractions (usually in the form of external dependencies) can only add complexity to the software, which has a detrimental effect on development effort. These "pointless" (but not really) dependencies we're talking about are the same as useful ones, but instead of weighing the cost against a more direct benefit (whatever the library gives), you're weighing it against these more indirect benefits, which is much harder. In my experience most people just give up and go with whatever sounds good, which is usually "use whatever people are familiar with". That subset of tools grows and grows over time, and if you just always go with the defaults, eventually you're going to end up stuck in the mud, because nobody is weighing the cost of your abstractions.
  - stcredzero 7y ago
    These "pointless" (but not really) dependencies we're talking about are the same as useful ones, but instead of weighing the cost against a more direct benefit (whatever the library gives), you're weighing it against these more indirect benefits, which is much harder. Facades and the various "layer" style abstractions aren't pointless. The whole point is to add a layer of indirection, for the benefit of being able to switch out underlying dependencies. The whole point is to make it easy to migrate off of a dependency.