Could a single web framework popularize Python?

[Ian Bicking]

On Thursday, October 9, 2003, at 06:56 AM, Alan Little wrote:
> I see no real likelihood of python ever eating a significant chunk of
> the  corporate big systems market - there's too much already invested
> in J2EE (not to mention older architectures that are still heavily
> used like CORBA and CICS). Java is more than good enough for the job
> and the skills are readily available. Why would anybody risk their
> company and their job on a completely unproven environment just
> because it happens to use a nicer programming language? Coding
> productivity as such is less important in this environment than proven
> reliability and compatibility with existing environments.

While you might be right that Python won't get a significant chunk of 
J2EE, for Python just a small chunk would be a huge win.  Taking 1% 
from Java increases Python by 100% (okay, I'm making up the numbers).

Of course, Java isn't the only web development language to compete 
with.  Both PHP and Perl are quite significant, especially for a 
certain demographic (the hacker type, vs. the Professional Programmers 
that use Java).  Personally I think Perl is on the way down, and has 
been for a while -- Perl 6 is a disaster that won't even arrive, and in 
general the thrill of Perl is gone.  PHP is almost more vulnerable, 
because it's support is so shallow -- at least Perl programmers have a 
certain loyalty, PHP programmers usually just fall into the language.

Of course, as a Free Software advocate in general, I (we) shouldn't 
really celebrate their loss.  Java would be a more appealing opponent.  
Or more appealing yet, if we could be the alternative for people who 
might use ColdFusion or ASP.

PHP's success, as I see it, has been from its shallow initial learning 
curve (nevermind the ceilings you'll hit).  Beginning web programmers 
get stuff done quickly, it keeps them working, and if PHP is used in 
larger, more formal situations it's because those 
once-beginning-programmers have some influence later on in their 
careers.  I think ColdFusion and to a degree even ASP are similar.  
Maybe Python can have a similar success.  We aren't going to sell to 
the top, but we have something good to offer the bottom.

> Yes I know there are exceptions. "Google uses python" etc. etc. Google
> started four years ago and did not have millions already invested in
> Java, Cobol, SAP, Oracle business-critical systems.

It's not like people have 20 years invested in Java.  Nor that the 20 
years of investment of COBOL leads people to write web applications in 
that language.  So there's still room.

> And Google uses
> python for what? If they use it to drive their extremely high traffic
> and usually admirably fast web front end, they're unlikely to tell
> anyone how. And even if they did, their problem is very large numbers
> of simple, read-only transactions none of which matter individually.
> This is entirely different from, say, a typical financial system where
> you have fairly large numbers of update transactions, some of them
> complex, where the integrity of individual transactions matters a
> great deal.
>
> What do you mean by a "web framework"? In the Java world, JSP and
> servlets are a subset of J2EE, the rest of which is aimed at
> scaleability and transaction integrity for big corporate applications
> that might just happen to have a web interface as one of their front
> ends.  (A large proportion of corporate back office systems that are
> *really* serious about scaleability and transaction integrity are
> probably still running CICS on mainframes, but that's a whole 'nother
> story). Full-blown J2EE is overkill for [practically anything?]
> applications that just want read & update one database via a web front
> end.
>
> So are you talking about a python equivalent of Tomcat, a python
> equivalent of jBoss, or a python equivalent of the J2EE standard (with
> something like Tomcat as a reference implementation of part of it),
> where different products could implement different subsets but there
> would be at least some hope of interoperability and portability?

Since Python isn't proprietary, and doesn't encourage proprietary 
offerings, something like the J2EE standard is unnecessary.  An 
implementation *is* the standard, just like CPython is the standard 
definition of the language.

 > I'm
> not necessarily saying that an overblown formal standard like J2EE is
> the best way to go. "Rough consensus and running code" is a better way
> to arrive at de facto standards that actually work in the long run.
> But in the python web world at the moment there seems to be a surfeit
> of "running code" in varying states of maturity, and no discernible
> "rough consensus" about how to hang it all together.
>
> Learning J2EE for a Java programmer is easy. If you're being paid by
> your employer to learn it, you use what they use. If you're doing it
> with your own time & money, the only decision you have to make is
> which servlet engine to use in front of jBoss. Either way, you spend
> maybe half a day installing and messing about with deployment files,
> and you're off. You may not be taking much advantage of all the
> facilities the environment has to offer, but you're up and running and
> can learn gradually from there - the mountain is high, but the
> learning curve isn't steep. (Horrible mixed metaphor, sorry).
>
> With python, you face a non-trivial research project even deciding
> which environment you're going to use.
>
> The thing you're going to hear most about is Zope, but you're also
> going to hear that Zope has a high & steep learning curve before you
> can  get anything working at all, and that even although Zope itself
> is built using python, any existing python skills you may have aren't
> going to be particularly relevant for building applications that use
> it, for which you're going to have to learn some wierd template
> language instead. I don't know if these things are necessarily
> completely true or up to date, but they *are* what newcomers hear, and
> in the case of this newcomer they were enough to put me off even
> considering learning Zope.
>
> If you decide not to use Zope, you have a choice of a wide variety of
> wierd & wonderful offerings that address different but overlapping
> subsets of the problem at varying levels of prototypishness.

The irony is that there's lots of offerings, but there's not actually 
lots of diversity.  Most people just keep creating the same boring 
infrastructure over and over, with small changes that provide a 
slightly better fit to their coding flow and aesthetic sense.

There's a few novel offerings -- Zope, maybe Woven... and I'm not sure 
that novelty is a good feature anyway.  The rest are just different in 
the details, and maybe have a different subset of features.

I feel like I'm sounding very pessimistic now.  Maybe I am.  The 
current state of affairs is boring!  Perhaps the worst sin of all...

> There is
> no consensus as to what the emerging or de facto standards are, no
> particular reason to believe that whatever you choose will be
> supported or widely used in three years time - and if it isn't, the
> skills you're invested your valuable time acquiring won't be directly
> usable with whatever else is around. See the J2EE example above - if
> BEA were to go out of business, the Weblogic folks wouldn't have much
> difficulty switching their hard-earned skills over to jBoss.

Eh, I don't worry too much about that.  As long as the framework isn't 
insular (which might rule out Zope and asynchronous Twisted 
programming) it's easy to translate knowledge into another framework.  
Python is Python, and that's really where your application is written.

But if there was some sort of standardization, I personally feel 
strongly it should support the current frameworks running on top of 
that standard.  The early adopters don't deserve to be jilted, and 
that's no way to build confidence in the standard either.

> My personal decision was that the advantages of python as a language
> are so great that it's worth spending a bit of time finding something
> that will run it nicely behind a web server for small personal
> projects. I chose webware and I'm having fun playing with it. In its
> current state I wouldn't feel at all confident about using or
> recommending it for any kind of serious production system, even if it
> was in a greenfield situation where the comments above about legacy &
> compatibility didn't apply.
>
> I don't understand all this talk about twisted as a transport
> mechanism. The web runs on Apache (~70%) and IIS (~25%). Anything that
> aspires to be at all widely adopted has to have speed and stability
> running behind one or both of those as one of its primary goals. I
> don't know much about twisted - perhaps somebody could explain where
> it fits into that picture?

Twisted's HTTP probably isn't the most interesting part -- it's 
certainly not what attracts most people to it.  More interesting is 
Twisted's support for other protocols, like Jabber or SSH.  Being 
Python it's a bit more nimble, which is something the core of Apache 
can't offer for the aspiring low-level networking programmer.  Also 
Twisted is a bit easier to pull apart.  Then there's the asynchronous 
programming -- you love it or you hate it -- but that's another 
discussion.  (Honestly I've never tried it enough to know, but I'm so 
skeptical of the ability of asynchronous programming to appeal to a 
general audience of programmers that I haven't bothered to give it a 
real try)

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org