“What you don’t know can’t hurt you” — but it can’t help you either.
Like many others, I suppose, I fell in love with Rails because it “Gets out of your way” so well. At least at first.
Thanks especially to Ruby’s dynamic method modification and anonymous blocks, Rails hides a lot of the details from the user. I still can’t think in closures, because I’m an implementation fetishist, but most of the time you don’t need to know how something works. And moving it out of way only helps you concentrate on what you’re doing. Until you need to do it some other way. And then cleverness bites you.
Like it always does in perl. Sure, a solid grasp of *how* OOP works makes it possible to understand how OOP in perl works, but you’re spending too much time showing how it works in you code to get the biggest benefit of OOP — simplification. Which is probably the most underdelivered feature of OOP anyway.
But a good framework shouldn’t do too much magic.
For one, it makes people like me — people who like to poke their fingers in the black box — nervous. There might be something sharp, or something you can break inside that box. And learning that box’s implementation as well as it’s interface gets to be too big of a burden.
Well, I suppose I should discipline myself and leave the lid on the box and get my work done…but that wouldn’t be ideal, would it?
“But what if I need to pop the hood and fix something?” that voice in my head says. I probably overestimate my need (or capability) of fixing (or improving, or modifying) the engine inside that framework box, but there you have it.
I like CodeIgniter because it’s obvious about what it’s doing. Maybe 91% of that is their really good documentation, but then maybe that’s 91% of this requirement.
The rule I take away from this requirement is that you should avoid unnecessary layers, like ORM and templating. They shouldn’t be central features at least. People have no trouble dismissing things authentication and authorization as external, but consider their ORM tool or templating system or CMS interface to be the core of their framework.
Maybe I’m just wrong (or different) in my thinking that authn/authz are core, or maybe it’s just the type of apps I tend to develop. But I’m willing to accept that their external if you’re willing to accept that your feature is. Or I guess different frameworks have different “themes” based on their focus — content managment, presentation, persistence, or authorization.
Another reason to be obvious about what you’re doing is that it makes it easier for us humble demi-hackers to work on. Less magic means less powerful magicians can provide meaningful contributions. That’s one area where CPAN shines and PEAR flounders. PEAR’s coding conventions are a barrier to entry. CPAN has tests that accomplish the same thing (better) and allow ranking without disallowing contributing.
Being able to understand how your framework works allows you to work within the framework, rather than trying to work around it.
When I first started in PHP, I really struggled with session caching, and db connection pooling because I sensed that I wanted something more, and when Java frameworks started to offer tools for this, I was easily swayed, swallowing the camel to get at the fools’ gold, or something like that. But when I better understood PHP’s shared-nothing architecture, and Apache’s MPM process strategy, I realized that it was a waste of time to try and build that stuff into PHP.
The final reason being obvious about what you’re doing is because sometimes that voice in my head is right and you do need to open the box, even if it has so fare been a gift from the Gods. And then you can only hope that you’ll be able to figure out what it’s doing.
Magic tools are fine when they increase productivity or abstract away implementation details, but for the suspicious and superstitious, being able to see how that magic is performed is important.
Which leads, unsurprisingly to my next requirement for the ideal framework:
“Leveraging existing knowledge and techniques”