The problem with 'over-abstraction' is not too much abstraction per se, any more than the problem with 'oversimplification' is excess of simplicity, or the problem with 'overgeneralization' is too much generality.
Abstraction, simplicity and generality are, in themselves, desirable properties in a design, since they reduce the bulk of design concepts we have to fit in our heads. You can't have too much of these.
You can, of course, make things worse for yourself by neglecting other design goals while striving for a particular one, or by stalling progress in your project by spending too much time in analysis paralysis.
The decision is not only between less or more abstraction, though. There are 'better' and 'worse' abstractions, as measured by their ability to show what is important for the client and hide the irrelevant. In Joel's examples of leaky abstractions, you can say 'too much' is being hidden. I'd rather say the wrong things are being hidden, or that it's done in the wrong place. You could conceivably hide 'more' irrelevant details while still letting every part of your program see what it needs.
To further complicate matters, the fitness of an abstraction for practical purposes depends on cultural factors. Some powerful abstractions only help if you've made the investment to learn and internalize a certain way of thinking about programming. On top of that, you may need to consider the skills and preferences of your audience.
In the example at hand, if Java needs 100 lines to perform an operation, while Python does away with 3, it's hard to argue that Java is being too abstract, or, indeed, more abstract at all. You can say it overindulges in 'abstractions'. But note that the end result burdens the user with lots of details that are irrelevant to them. That is exactly opposite to what abstraction is all about.
The problem with 'over-abstraction' is not too much abstraction per se, any more than the problem with 'oversimplification' is excess of simplicity, or the problem with 'overgeneralization' is too much generality.
Abstraction, simplicity and generality are, in themselves, desirable properties in a design, since they reduce the bulk of design concepts we have to fit in our heads. You can't have too much of these.
You can, of course, make things worse for yourself by neglecting other design goals while striving for a particular one, or by stalling progress in your project by spending too much time in analysis paralysis.
The decision is not only between less or more abstraction, though. There are 'better' and 'worse' abstractions, as measured by their ability to show what is important for the client and hide the irrelevant. In Joel's examples of leaky abstractions, you can say 'too much' is being hidden. I'd rather say the wrong things are being hidden, or that it's done in the wrong place. You could conceivably hide 'more' irrelevant details while still letting every part of your program see what it needs.
To further complicate matters, the fitness of an abstraction for practical purposes depends on cultural factors. Some powerful abstractions only help if you've made the investment to learn and internalize a certain way of thinking about programming. On top of that, you may need to consider the skills and preferences of your audience.
In the example at hand, if Java needs 100 lines to perform an operation, while Python does away with 3, it's hard to argue that Java is being too abstract, or, indeed, more abstract at all. You can say it overindulges in 'abstractions'. But note that the end result burdens the user with lots of details that are irrelevant to them. That is exactly opposite to what abstraction is all about.