Ian, I appreciate a lot what you have written lately. But let me drop my $0.02 about this post.
You write in the penultimate paragraph "Python can be the next system like that, ..." For me, this sounds like a deja vu. I heard it when the shining star of Perl CGI started to fate. I heard it again when Zope raised to relieve us all. And now again... Don't get me wrong, I love Python. But I am currently looking into rails, cause it fulfills it promises and isn't the next prophet to make a Python framework the tool of choice.
In my eyes, the most promising Python web framework is Django. Not based on its features and so on. But just because how it is developed, maintained and documented. Everything is well integrated, works fine and feels as a complete tool. TurboGears started nicely. Kevin has some great ideas. But then he entered the PJE road of release management, or better said the unfinished aX-Notation like 0.8a5. I wait for the first time, when he is heading straigt from 0.8a6 to 0.9a1 or whatever, just as the release for setuptools walk.
If I understand you correctly, you also say that it is good to integrate existing tools. Right? This is what I thought you meant, by saying that you can't develop everything on your own and can't be cutting edge if you do everything yourself. Basically, I think you are right. But then I look at my TurboGears mailing list archive and see, that you have to do two things to succeed with such a project. First, be a benevolent dictator and steer the project, steer the discussion and shield your users from the discussion about the underlying technologies. Do I care about wether SQLObject, Og, ActiveRecord, Hibernate or whatever is used? Not at all to be honest. And if I see people discussing this stuff, it makes me uncertain. Same for using Paste, WSGI (this is also a nice point, where regularly shake my head), and so on. I still think that you are basically right, but Rails and Django are proven examples why it can be good for a project, if everything is integrated well and market as a solution. This is a lesson I (the technology guy) learned from the sales guys. The second lesson I learned was, that it is also sometimes crucial to be not a benevolent dictator and stop some discussions. :)
Just for the protocol, I don't want to lower the job Kevin Dangoor has done. He has done a great job. The only problem was, that the usual prophets showed up and he didn't went backstage with them.
And for the same protocol, I agree with you that Rails is not the panacea, the holy grail and the end of development. It is an implementation of an idea. And currently the best available in my eyes. But good things will follow, and may be from the Python community. But the Python community has to get rid of its attitude to some degree to achieve this. In my eyes a lot of Javaism is showing up in the community, which is in the end not compatible with the idea Rails follows and a lot of people enjoy to follow in the future. Pragmatism is something, that (we|the) Python guys sometimes lack. And may be it could be helpful if not all people would implement there own base technology but integrate existing stuff.
You write in the penultimate paragraph "Python can be the next system like that, ..." For me, this sounds like a deja vu. I heard it when the shining star of Perl CGI started to fate. I heard it again when Zope raised to relieve us all. And now again...
... and now again we should try to make it work...? That's what I read from the history, not "it didn't work before, we shouldn't try again." Zope has some good goals, ones which we shouldn't abandon even if the product wasn't manageable, and we should learn lessons from the problems Zope had.
I guess I should probably try to analyze exactly what it is that PHP is good at (and Perl CGI before it); but you can probably imagine what lots of its good features are as a platform.Do I care about wether SQLObject, Og, ActiveRecord, Hibernate or whatever is used? Not at all to be honest.
Maybe not, but I sure as hell do. And if you start using Django heavily, you will start to care when another framework comes along and uses a different ORM. And you will care what that ORM does, and you will care about URL dispatching, and all that stuff. And if you want to use that new framework, you'll care about how hard it is to maintain both alongside each other.
If you are just jumping ship and moving to an entirely new stack, these things don't matter to you. And maybe targetting those people is a perfectly good strategy -- for some stacks it's probably just as well that they are abandoned. So Rails has seen lots of PHP and Java programmers; and because previous investments in Ruby have been rather small previously, it's been able to get the Ruby programmers as well.
If you want to get people into Python the same way, that's fine. You won't get me, because that's not where I am. More than once people have asked me: why not just all use Django? Personally I don't know what the hell they think I'm going to say.
But even then, that's fine. If you had to buy into reuse to participate in the kind of WSGI-based stack I imagine, that would invalidate the inclusiveness of the stack itself.In my eyes a lot of Javaism is showing up in the community, which is in the end not compatible with the idea Rails follows and a lot of people enjoy to follow in the future. Pragmatism is something, that (we|the) Python guys sometimes lack.
There's some vague accusation underneath these comments that I dislike (ditto the Frankenweb post I reference in the article). It's using Javaishness as the same kind of blunt stick as not-Pythonic-enough.
These are practical issues. Being able to install an application easily is practical. Being able to embed other applications is practical. Introspection and uniformity at some level is practical. And yes, reuse it practical, at least if you think that anything you build matters.
Maybe you can't imagine building anything that can't be built in a few weeks today. I can imagine those things, things that I want to build in a few weeks but can't. If all we do is write and rewrite and refactor the same kinds of stacks, we can't get there. At some point we have to put pieces of the stack behind us, to make them stable (as in API-doesn't-change, as in mature and boring), to create a real foundation. That simply can't happen on the level of a typical web framework -- you still have to have a framework, at some level you have to get things done, but the framework isn't where we can build up that foundation.
I'm sorry if you don't understand the motivation or purpose of some of the things I work on or talk about. I do want to explain them better, but sometimes I don't. But labelling that confusion as though I'm therefore caught up in meaningless academic discussion is a little offensive. If you think it's too complex, say so; if you think it is unapproachable, say so; but there are deeper and more abstract ideas underneith the surface of immediate pragmatic concerns, and they do matter sometimes.# Ian Bicking
I would like to add that all the buzz around the frameworks is often generated by people doing only web applications and not having to access other business models/logic from within. These needs to integrate, reuse the ORM coming from the business side of the application, are often simply not addressed today. So +1 for the FrankenWeb, because my web is linked to grids and software stacks that cannot be handled by a "unique" framework.