"Frameworks have no requirement to be minimal in size while maximal in features."
I notice that he describes what makes a good library good, but there is no mention of what a good framework might be. The implied conclusion, of course, is that there is no such thing as a good framework - once you're a framework, you've gone off track and created something that isn't very useful, and you should turn around and go implement a library. Guido is not the first person I've heard make this assumption, but he is the first person I'm inclined to take seriously.
My understanding of the distinctions between "frameworks" and "libraries" is that frameworks, in general, tend to call your code through callbacks, whereas libraries don't need to call your code. Under that definition, all existing GUI-building tools would be "frameworks", but nobody calls them that, the convention in the GUI world is to call them "toolkits". The convention in the business software world seems to be to call them "application servers".
I'm not sure that the definitions of these terms are generally accepted, though. FOLDOC says a framework is "a set of classes that embodies an abstract design for solutions to a number of related problems", and a library is "a collection of subroutines and functions stored in one more files, for linking with other programs". Neither of those definitions say anything about what code calls what other code, or how such things are designed. In fact, the way that they are presented there, the terms are nearly synonymous in the context of Python.
I think that regardless of terminology, all software has the obligation to be minimal in size while maximal in features. Also, software should be incredibly fast and well-documented, and user-friendly. Of course it's usually impossible to be all of those things; the design constraints imposed are a complex fusion of the application domain and the intended audience.
However, in light of the growing acceptance of the word "framework" to mean "a really bad library that started out as an application", maybe we should stop calling Twisted a framework. What's a better word? "Toolkit"? "Environment"? "Integratotron"? Discuss.
Posts
11 comments:
Having only a limited experience with Twisted I may not the best person to respond to this, but it seems to me that the slow componentization of much of the Twisted codebase is already making it more and more of a mixed-breed.
Those things that feel most like frameworks to me tell me to put my code in a certain directory, or better yet edit a certain file they have already provided or I create after running some sort of generation script. They have me define a set of classes and templates that will all get glued together in the end. Twisted does not feel like this.
Sure, if I am going to run something with `twistd` I'll be intializing an 'application' variable at the end of my file somewhere and have to expect something else to know what to do with it, but nearly all of my actual use of Twisted has been more how I would expect a library to be, a massively cross-linked library requiring me to implement all kinds of interfaces to send data to its calls, but still a feeling of a library nonetheless.
The most Twisted forces my hand is on an interface level and that level of coercion is pretty much expected from any code that expects me to work with something like a protocol. To me, Twisted feels like a big set of protocol libraries where most of the grunt work has been done for me and a server I can throw the protocols at. Of course, there are large parts of Twisted that I have not used because they didn't make me feel this way.
So, "Integratotron" is my vote.
I was wondering how long it would take before one of you guys commented on Guido's post.
Framework, schmamework. It's a meaningless distinction for someone that is about the task of getting something done.
Oh, and "Integratotron" gets my vote if that's the choices we have, though I'd prefer "big mass of code that will suck your soul out through your ears if you're not careful" is my *personal* pet name.
I can't really place the tone of your message, but that example was of things I *don't* like, and the examples I was referring to were turbogears, django, ruby on rails, java things (i seem to have stricken their names from my memory) and almost every other web thing I've used.
The tone as it were is that "frameworks are the new black" and we've gotten frameworks crawling from the woodwork all of a sudden. Twisted, as a "framework", has been out there brake dancing for years, along with Zope doing a polka or two. These things are the Elder Frameworks, as it were. But Guido's just now wondering what a framework is?
TG is a "framework" of the "class of '05" that I've recently used, so your description very vividly recalled to me my TG experience.
Hm. "Elder Framework". I like the sound of that. Very ... creepy. :-)
"Java things." I'm gonna be chuckling over that one all night. Thanks for that :-)
People need to stop confusing control flow with control.
Nobody wants to use a "framework", because it will constrain their application too much, or require too much from their own application. People want control of the design of their application, and so they want to use libraries or toolkits.
One important way that a framework can take control from you is to require that you use all of it or none of it. In constrast, a toolkit is a collection of things, many of which work well together, but all of which could be used in isolation if you really wanted to.
The issue of which code is above which other code on the call stack ought to be considered separately. Nobody agonizes that wxPython is an unwieldy framework that takes away their control just because it sometimes communicates with their app by events instead of by return values.
It is a typical geek mistake to try to define terms like "framework" in terms of some technical criteria -- Does it come with stabs symbols? Does it have an XML API? Does it favor continuation passing? But technical details cannot define "framework" or "toolkit" -- they are social and emotional terms, not technical terms.
Anyway, I'm glad that you -- Glyph -- are sensitive to this marketing issue.
But I'll try to keep it concise.
1) Guido's comments may very well have some deep insight associated with them, but he failed to share that. It just sounds like whining to me. That and being tickled about a snarky comment, giving me the impression of something more like propaganda than genuine analysis.
2) I've always had a view similar to that defined by the FOLDOC. To give further voice to the same: frameworks are about solutions in specific problem domains and libraries are about general utility (with which you may build any solution you desire).
3) I believe that the reason people do not like frameworks is because they don't want to learn a new "language". They want to continue using the syntax, structures, best practices, etc., that they already know. What they continue to ignore is that the framework is about a problem domain. The continued use of any self-consistent set of solutions for a problem in a given domain will necessarily generate its own pattern language. Saying that one don't like the fact that frameworks have pattern languages which we have to take the time to learn is not really saying much about the framework. Such complaints get interpreted in my brain as "why do self-consistent solutions in problem domains exhibit emergent behavior?" or "why can't someone add a layer on top of these solutions (the framework) so that I don't have to really think about the problems?"
I have 2 slightly more serious suggestions, which I might discuss in a top-level post if I have something more interesting to say about them:
"The Twisted Networking Engine"
or
"The Twisted Networking Platform"
I suspect that "Platform" may be a bit more descriptive, but will still evoke some of these same negative concepts from "Framework". "Engine" evokes game engines, rendering engines, both of which are more exciting-sounding than other things named "platforms".
Amen.
The interesting thing about Twisted is that there is a HUGE amount of effort spent making sure that it isn't mutually incompatible with any code that it doesn't have to be - many networking / mainloop libs break if you integrate them with a GUI, or vice-versa. Despite "playing well with others" in that way being a hard requirement for Twisted development for years, there is still a widespread misconception that you can't use Twisted with any other libraries, and that it immediately consumes your whole codebase, just because it lives above you on the stack.
(Why do I have the strange feeling that someone is going to quote that as "Project leader Glyph says 'you can't use Twisted with any other libraries (...) it immediately consumes your whole codebase'?)
"The Twisted Networking Engine"
+1
For me, "engine" has connotations that imply:
* the best of what frameworks have to offer
* voluntary buy-in to the product and the implicit process (assuming that when you're choosing an engine, you know what you are getting into... as opposed to buying a complete car or simply a set of plans for a car...)
I am confused.
You think it's a bad thing that it's easy to write software (for the web) because then lots of people will write software (for the web)? I guess instead writing software should be super hard and expensive?
(I must be misunderstanding you.)
Post a Comment