I’m tired of software-development frameworks — they seem always to be optimized for the way someone else works, or for the way someone else thinks I should work. Granted, it’s fun to write frameworks, and it’s almost as much fun to learn them, but as soon as I try to do anything non-trivial they either get in my way or lure me off the road into blind alleys.
Is this a serious defect in my own skills and practices, or do others feel the same way? To paraphrase an almost-famous saying by Tim Bray, here’s what I want most from a development environment:
- Turing complete;
- good library;
- get out of the way.
Quoderat 
Frameworks are necessary for what is called software engineering, which Dijkstra sardonically defined as “How to program if you cannot.” You need them when you are working on a project too large to hold in any one hacker’s head. They suck, but churning out tens of thousands of lines of almost-repetitive code to handle the weird and idiosyncratic little details that every customer demands be done differently or else can’t reasonably be done any other way.
Wouldn’t
* Turing complete;
* good library;
* get out of the way.
be considered a framework? I can understand the fact that you don’t want to deal with bloatware frameworks that force you into doing things a certain way to accomplish a task. But a framework is a framework, whether that be commonly used modules in Scheme or Python that are grouped together to make common tasks simple (e.g. TurboGears) or whether they be Win32/COM or .NET DLL’s.
I have to say I sympathize with your point of view, but I’m not sure this is really black-and-white. To take some randomly chosen examples I find the framework approach taken by Axis (Java SOAP implementation) to be tiresome for exactly the reasons you give. I’d be much happier did not take the framework attitude (don’t call us, we’ll call you), but instead left me with more control.
On the other hand, when it comes to frameworks like Swing I really prefer the framework approach. There’s just too much to worry about, and I’d rather someone else took care of it, even if it does force me to work their way. The same goes for the operating system, I guess. 🙂
Thanks for the comments, John, David, and Lars.
John: That’s the clearest argument I’ve ever seen in favour of frameworks: to elaborate, frameworks are a bit like project managers — unpleasant, but sometimes necessary once you have a certain number of people working on the same code. A large application is always going to need some kind of well-defined top-level architecture to allow people to work together, so the real question is whether an off-the-shelf framework will make a good fit or the top-level architecture should be customized for each application. Unfortunately, the large projects that I’ve seen that used frameworks like Struts or Spring have tended not to use them consistently, as if the framework were something that the developers had to work around.
David: I don’t know if this is universally accepted, but my definition of a framework is something that takes over much or all of the top-level control flow of your application — in other words, instead of your application serving as the glue that holds the library components together, a framework serves as the glue that holds your application components together. High-level library functions don’t constitute a framework, because you still call them when and where you want.
Lars: Swing is an interesting borderline case, as is SAX — since they use callbacks, does that make them frameworks? Since I can use Swing components individually in several different kinds of application architecture, I might exclude Swing; SAX *has* to use callbacks, though, so it really does constitute a parsing framework, though not a full application framework.
I’m reminded of Spolsky’s Law of Leaky Abstractions: http://www.joelonsoftware.com/articles/LeakyAbstractions.html