I read somewhere (wish I could remember where, bizarrely I think it was on paper) that the very definition of a framework over a library is that inversion of control - ie your application runs inside the framework - you are beholden to its lifecycles and view of the world.
When on the JVM, I use scala - and I have found very little utility for frameworks. Libraries - oh yes, very much so.
Yeah, I think that might actually be the definition now that I think of it. I do think there are some cases where that inversion of control makes sense, but it really has to be cases where there's no sensible way to proceed with anything other than total buy-in to a particular way of doing things. For example, it's fine that something like the Unreal Tournament engine is a framework. If you're going to write your game in the UT engine, you're really going to have to write it in the UT engine, and commit to doing things the way it does things; there's no sensible way for you to just use the UT engine as a library subordinate to your game. But I don't want to do that sort of thing very often or lightly.
I read somewhere (wish I could remember where, bizarrely I think it was on paper) that the very definition of a framework over a library is that inversion of control - ie your application runs inside the framework - you are beholden to its lifecycles and view of the world.
When on the JVM, I use scala - and I have found very little utility for frameworks. Libraries - oh yes, very much so.