Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Although this article never mentions the word, it's really about abstractions, not "implicitness" per se.

No one would say that if you have an almost-perfect abstraction, like a physics equation for fluid dynamics, that you should go to the effort of dropping down to the lower level (specifying what each molecule should do, in this case).

The problem is that this ORM example is an extremely leaky abstraction. Several of the inferences it is making are inferences that are not predictable if you don't already know how it will work. And they are inferences that matter.

Anyone who has ever used an ORM knows that it seems like magic, right up until you try to run some large query and it takes an eternity, and then you have to unpack it all and add all the explicit stuff to fix the problem that you "avoided" in the first place.

The real art of programming is in knowing what needs to be explicit and what can be implicit. I'd agree that if something can be made implicit without mystifying callers, it should be.



ORMs make the obvious and easy things even easier. They don't help out as much with the hard stuff. The hard things are still hard regardless if you have an ORM or not, but just because an ORM doesn't solve everything it doesn't mean you should throw the baby out with the bath water.

You rarely have to "unpack everything", you usually just need to go down a level of abstraction or two to get at the actual database driver in specific parts of code.

The trade off of using an ORM is still almost always worth it in my experience, but it certainly depends on what your app does.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: