at some point it's a debate on definition. To me, a "framework" as a strawman (and unfortunately, usually in reality) has the following features * hoses the st

at some point it's a debate on definition. To me, a "framework" as a strawman (and unfortunately, usually in reality) has the following features * hoses the stack trace and makes stepping through code useless and futile * introduces nearly indistinguishable vague abstract ideas that have very real differences in code that are not well-documented * changes core api and underlying functionality every few months and breaks backwards compatibility * makes code action-at-a-distance spaghetti where one task is strewn around multiple files in different directories through some mystical dance of indirection * is an order of magnitude slower while claiming to be zippy, lightweight, and fast * constrains and restricts how you can use the language and express your ideas * rewrites or suppresses core diagnostic, logging, and debugging features built into the language with their own variation (usually called something like EasyLog or SplendidDebug or some nonsense)... * shoehorns your problem into a very specific and narrow domain * introduces new configuration files and changes their formats at nearly every version * does things very naively (such as busy-polling a file to look for changes, pegging a cpu core, instead of using inotify(2)) * has marketing like a new iPhone so everyone is onboard with the hot-newness of it all * will be dead and abandoned in about 18 months. It's essentially people who don't know what they're doing trusting other people who don't know what they're doing all surrounded by mountains of hubris