* Oliver Jones <oliver(a)deeper.co.nz> [2005-04-23 05:15]:
Sometimes over-engineered frameworks can be very helpful in providing a consistent and well tested set of foundations upon which to build.
I disagree completely. I probably agree with the intent of what you’re saying, but I can’t let this statement stand as is. Architecture astronautics lead to a lot of entropy for not much gain. Frameworks are helpful when they try to address a problem, not when they try to make you build your application around them.
It is better to start with solid foundations than to try and stuff in more solid foundations as an after thought when your programs requirements expand.
Yes; that is why a framework should try to address its problem space very thoroughly. Another example of this is the Template Toolkit, a suite of Perl modules for, well, templating. It does *everything* and then some that you’d expect to ever want from a templating system, but you have to do almost nothing to start using it. You can use as much or as little of it as you want.
If the framework is good it shouldn't require you to do a lot of work to start using it. Log4* is like that. It is relatively simple to get up and running with it.
Yep. Good frameworks stick to their purpose and come with sane defaults and a good swath of convenience interfaces. That's what Log4perl (and probably Log4* in general, which I have no experience with) is like. What I was saying is that when I see “flexible application framework”, that *usually* means there’s some architecture astronaut[1] at work. [1]: http://www.joelonsoftware.com/articles/fog0000000018.html Regards, -- #Aristotle *AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}; &Just->another->Perl->hacker;