Frameworks tend to arise in languages with poor composability. Composable languages favour large numbers of small libraries which can be mixed and matched in many creative ways. Composability favours design.

Of course. But no one seems to be suggesting otherwise, that I can see, and for the relatively common case in which one needs quickly to prototype and roll out something which does "fit neatly into a predefined box", a framework is often just the thing.

You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such.

And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together.

"And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together."

Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything?

I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".

Who said anything about writing a whole language? Just know the language you're writing in well enough that you can build something better without a framework than you can with.

Well, sure. When I need something like URL routing, or object-relational mapping, or templating, why not reinvent it from scratch every time? Or, failing that, why not handle things like that with a collection of favorite libraries, each of which has its own calling conventions, its own requirements, and its own attitude toward the world? Reconciling all those differences certainly won't take a significant amount of time, and I'm always happy to spend my efforts on tooling instead of on whatever project inspired the need for tooling in the first place.

More seriously, I can understand where you might be coming from with the implication that frameworks are a crutch for developers who don't bother to learn, or aren't capable of learning, the language in which the framework is implemented; I've had to clean up the wreckage left behind by Ruby on Rails hacks, too.

But what's important to keep in mind is that the Rails dev community is extremely atypical in its extremely low average level of basic programming capability, and the Rails framework is likewise anomalous in the degree to which it forgives such incompetence. These traits, I stress, are not common to frameworks in general or to the developers who employ them, and consequently it is very much a mistake to use the Rails ghetto as a basis for extrapolation to more or less anything else. It's your mistake to make, of course, and if you insist upon it, then I won't go to any further effort on your behalf. But you can't say no one tried to warn you.

Prototypes always end up in production, framework or not.

I've seen this happen over over to the point where work prototypes are not terribly removed from production code.

I prototype slower, but nobody cares.

I just try to write production quality prototypes these days. Django is a godsend for writing maintainable solid agile database applications.