Re:A2Z: A computer designed and built from scratch. Custom C...
by greenshackle2 on Sunday August 26, 2018 @01:30PM
(#17846830)
Yeah, I can agree with that. You'll get the most value out of understanding the 1 or 2 layers below. Digging all the way to bare metal is usually not necessary or practical, though it may help once in a long while.
For example, ORMs. If you try to use an ORM without knowing SQL you will have a bad time as soon as you hit performance issues or you have to do something that doesn't fit quite nicely into the ORM model. I have yet to see a project that uses an ORM that doesn't use SQL in places.
ORMs are not necessarily net positive. They make some things simpler at the cost of an extra layer of indirection.
Going a level deeper, knowing how query planners work at a high level will help writing performant SQL queries.
Going as far as understanding how your RDMS is implemented should not typically be necessary. It would help for finding bugs in the RDMS, but that should be very rare.
When the subject of many layered JS frameworks and dependency graphs with hundreds of mini libraries comes up I'm always reminded of Rasmus's 30 second ajax tutorial: https://web.archive.org/web/20060507105529/http://news.php.n... (And the modern equivalent: http://youmightnotneedjquery.com/) Very often libraries and frameworks are brought in because they "help us go faster [because of x,y,z]" with some x,y,zs like "we don't have to think about that problem" or "the global architecture/structure is taken care of", but the cost of dependencies sometimes outweighs the cost of thinking about the problem and doing it yourself. Libraries and frameworks are tradeoffs, you'll likely use a lot of them if you look at every layer you can actually influence, but they're not necessarily net boons.