Leaky abstractions, especially with recursive programming drives the user to read the code that refer to the code that refer to the code (and repeat) just to locate an issue at some low-level function… In many use cases, a user should not have to read and understand the library function in its entirety just to use it – it’s supposed to off-load the work away anyway. The ideal case would be to have a function that works in almost the English sense of the name of the function. People are working towards context-detection so that programs knows the context within which the user is applying the function in, and calls the right implementation without throwing an error.
However, the on the other end…
Hiding all the implementation details underneath the hood is also removing the possibility of understanding the tool. If the tool is well designed, well and good, but if not, and if the tool works against or hurts the wielder, then there is no easy way to change the tool. People are then forced to work for the tool (fix the computer, maintain virus checks etc…), instead of having the tool work for her.
Two examples:
- when you see a blue screen in Windows, you are given a code and you need to ask your system administrator.
- using Mathematica, you don’t learn math at all, you just call the function and it should just work, but you don’t learn the math at all and when it returns an elliptic integral of the n-th kind, then what can you do…?
To hide or to leak, that’s the question. And how to hide if it should be hidden and how to leak if it should be leaked. This calls for wisdom.