<update>Note - i do think there such a thing as too many bad layers of abstraction</ypdate>
Abstraction is just scoping - you should know what each layer is about, even if you've only scratched the surface, but think of how many successful levels of abstraction you've been ignoring:
anyway, i coluld go on for a long while more, but as you can see you've got hundreds of layers of abstraction, but if we don't look at it that way, since they aren't really layers but more like a tree, we have 2 main layers that we care about:
My point is really this: know what's going on. Go read the Catalyst and Class::DBI source code. They are slightly tricky reads, since it's hard to see exactly what they are doing unless you've got the big picture, but the code is well written, clear, concise and useful. (Just think what would happen if they were written in assembler, eh?)
Once you know what's going on under the hood, you can forget the details. In fact, you don't even have to learn the details. If you practice this often enough you can read any module in 2-3 minutes, just to see what's going on structure wise, and guess most of the rest. When there's something you're not 80% sure of (80% is good enough) go check.
This way you can use your tools with confidence, work less, and still have control.
The only problem I have with abstraction that comes in one huge chunk all at once is the question "where to start". From a business perspective this means: is it going to be cheaper to learn this, or to rewrite what I need?
As you can see some modules (e.g. catalist) are more successful than others (e.g. openframe or whatever it's called) for doing pretty much the same thing. I guess it's really a matter of how much abstraction that introduces all at once, and how it's presented, because I tried reading the latter's docs and didn't really see what was happenning or what they want from me, but with Catalyst it was a breeze.
The reason abstraction is good (if it's good abstraction, that is ;-) is that you can capture repetitiveness in a well contained model. Functional programming is powerful but hard because the style it promotes is "abstract anything and whatever's next to that" - functions applying functions to the applications of another function, on data structures which might really be functions themselves ;-)... Object oriented programming gives us a style where we abstract slightly bigger things, and concentrate on how data looks alike, not how algorithms look alike. In this day of all these MVC frameworks I think that the functional approach is starting to apply on the application scale, to object oriented design.
Anyway, i have to leave now, but I think i'm sort of done... =)
In reply to Re: Is too much abstraction a bad thing?
by nothingmuch
in thread Is too much abstraction a bad thing?
by silent11
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |