Handwriting on the Sky - Is "Framework" the new "Enterprise"?

08:35 pm March 15th, 2006

You are viewing

glyf's journal
Create a LiveJournal Account Learn more

Explore LJ Culture Entertainment Life Music News & Politics Technology




			Handwriting on the Sky - Is "Framework" the new "Enterprise"? stranger than the night where black stars rise

glyf


	Is "Framework" the new "Enterprise"?
	I think that at some point, "Framework" became a dirty word, and I haven't noticed until now. From Guido's blog: "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.

14 comments or Leave a comment


	Comments

	From: anarkystic	Date: March 16th, 2006 02:10 am (UTC)		(Link)

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.

(Reply) (Thread)

	From: grimmtooth	Date: March 16th, 2006 02:48 am (UTC)		(Link)

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.

I smell Turbogears.

They're WAY late to the party if that's one of the examples you're thinking of.

(Reply) (Parent) (Thread)

	From: anarkystic	Date: March 16th, 2006 03:10 am (UTC)		(Link)

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.

(Reply) (Parent) (Thread)

	From: grimmtooth	Date: March 16th, 2006 03:43 am (UTC)		(Link)

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 :-)

(Reply) (Parent) (Thread)

	From: dreid	Date: March 19th, 2006 11:01 am (UTC)		(Link)
	Interestingly enough...

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.

This highlights a trend in web frameworks, people seem to be under the impression that it's a good idea for anyone and their grandmother to write a web application. I've never really felt this way, not because I'm biased against grandmother's (especially not glyph's) but because I tend to think web applications are a bad idea, and people actually writing them is an even worse idea. So a lot of "framework" developers have seemed to decide that it's really cool to make "writing an application" as easy as "configuring the framework." Should just anyone be able to build with a few clicks of the mouse and a few keystrokes into what amounts to little more than glorified configuration file? I'm inclined to say no, which is probably why I haven't been able to get all excited at the prospect of everything at divmod running on top of web2.

(Reply) (Parent) (Thread)

	From: glyf	Date: March 19th, 2006 03:02 pm (UTC)		(Link)
	Re: Interestingly enough...

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.)

(Reply) (Parent) (Thread)

	From: grimmtooth	Date: March 16th, 2006 02:46 am (UTC)		(Link)

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.

(Reply) (Thread)

	From: grimmtooth	Date: March 16th, 2006 02:50 am (UTC)		(Link)

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.

(Reply) (Thread)

From: zooko	Date: March 16th, 2006 12:47 pm (UTC)		(Link)
control flow != control over your design

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.

(Reply) (Thread)

	From: glyf	Date: March 17th, 2006 05:16 am (UTC)		(Link)
	Re: control flow != control over your design

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'?)

(Reply) (Parent) (Thread)

	From: oubiwann	Date: March 16th, 2006 09:00 pm (UTC)		(Link)
	oh, so much to say...

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?"

(Reply) (Thread)

	From: glyf	Date: March 17th, 2006 05:12 am (UTC)		(Link)
	Re: oh, so much to say...

"I believe that the reason people do not like frameworks is because they don't want to learn" (full stop)

Education is a huge problem, and it's never the way to get popular with the cool kids. Twisted Labs has collectively invested quite a bit of time and energy in the documentation, but clearly it's never enough ;). Even in the areas which are documented, you need the metadocumentation of "why should I bother to use this", which we are very short on, since if you know you need Twisted it is so obvious that it doesn't bear explaining.

(Reply) (Parent) (Thread)

	From: glyf	Date: March 17th, 2006 05:08 am (UTC)		(Link)

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".

(Reply) (Thread)

	From: oubiwann	Date: March 17th, 2006 05:23 am (UTC)		(Link)

"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...)

(Reply) (Parent) (Thread)


	14 comments or Leave a comment

profile


User: glyf Name: Glyph Lefkowitz Website: Scribbles in the Dark

calendar

page summary