What do you want in a new web framework?

[Cliff Wells]

On Thu, 2006-08-24 at 04:28 -0700, Paul Boddie wrote:
> Cliff Wells wrote:
> > On Thu, 2006-08-24 at 04:04 +0000, Tim Roberts wrote:
> > > Cliff Wells <cliff at develix.com> wrote:
> > > >
> > > >But there are interesting things in Ruby (and Ruby 2 should take care of
> > > >lots of warts Ruby 1.8 has) that Python could learn from.  All-in-all,
> > > >Ruby is mostly as good as Python in most ways and better than Python in
> > > >a couple key ways.
> 
> The big difference between Ruby and Python is the lifecycle phase that
> the languages/systems are in: Ruby arguably has room for a lot of basic
> improvements in the architecture of the virtual machine and presumably
> has a list of "must add" features that cover gaping holes with respect
> to certain audiences [1], whereas Python has been around for ages and
> has covered most of the critical gaps in the feature list (although we
> can always suggest things which bother our own part of the community).
> Whereas the Ruby people merely have to agree on how critical their
> missing features are and to move in one widely agreed direction, the
> Python people face a tougher choice as to what should be done next;
> strategies include a tidying-up exercise to make the language more
> coherent, a complete reimplementation, deep modifications to the
> runtime, the introduction of radical new semantics.

All true, but there's a more fundamental difference that's going to show
more as a larger number of people become used to Ruby's semantics: any
Ruby statement can be used as an expression.  This is firmly from the
Lisp family of languages whereas Python's statement-based syntax is
firmly in the Fortran branch.  With the exception of Lisp itself, no
language has seen the popularity of this style of programming until
Ruby.  I think this represents a real danger to Python's mindshare.
Once people have tried expression-based languages, they tend to be
loathe to return to statement-based languages.  To date,
expression-based languages have been mostly of interest in academia or
to a small group of elitists and so weren't practical to use for
day-to-day work.  Ruby has changed that and I think we're just starting
to see the fallout.  Rails may have brought them there, but Ruby itself
is keeping them there.  My fear is that the expression-based family of
languages is the Homo Sapiens to our statement-based Neanderthals and we
can either evolve or disappear.  Python is unique in many ways and I'd
hate to see those unique features lost because we're stuck on the wrong
evolutionary branch.

> The fewer obvious issues that a language has, the less energy there is
> in the community to deal with those issues thoroughly, I think. I guess
> the Perl community chose a bold new direction in line with the
> observation that a big vision can inspire much more in people than lots
> of incremental changes to an existing vision, but the energy required
> to follow through on such a vision can be immense. In addition to all
> this, a large existing community is more likely to want larger benefits
> for smaller levels of disruption because of the amount of existing
> code. Thus, the available energy for change is less in a mature project
> than in a growing project because people have to constantly monitor the
> breakage in their existing investments in the language.
> 
> > > ...but you can't READ Ruby code.
> >
> > Yeah, that's one of the big reasons I haven't seriously considered
> > trying it.  It's expressive, got interesting features... and appears
> > unreadable to me.  I'm usually pretty good at deciphering most
> > languages, even if I haven't used them before, but Ruby is one of the
> > exceptions.
> 
> My feeling is that I'd rather learn more about Lisp or Scheme than Ruby
> - the benefits are greater and for me Lisp and Scheme increasingly have
> the edge on readability. Perhaps I'm just not "tuned in" to
> Smalltalk-style syntaxes.

I'm in the same camp.  As I mentioned earlier, it's been mostly inertia
and the wealth of the Python community that's kept me with Python.
That's why I was so excited when I found Logix.  Lisp-like features with
Python's syntax that generates Python bytecode.  Actually Logix is
perhaps too far the other direction as it supports Lisp-style macros and
the creation of arbitrary syntax, which perhaps would justify some of
the fears people have of Lisp-like languages.  
The part I found appealing was having Python-like syntax in an
expression-based language, with the capability to integrate completely
with Python libraries.  Absolutely the best of both worlds.  I've been
trying to contact the author of Logix to find out what the status of the
project is or if he's abandoned it.  If you haven't looked at it you
really ought to.

http://livelogix.net/logix/


> > This brings us back around to the web framework debates.  For many
> > people Ruby "fits" their brains and for others Python does.  I think
> > frameworks are similar.  I tried Django and while I thought it was a
> > great product, it simply didn't "fit" how I think about that problem
> > domain.
> 
> I thought that the most interesting thing about Django was the URL
> mapping strategy it employs, although you have to be fond of regular
> expressions to really appreciate it, I think. 

Django's dispatch mechanism is flexible, but what I disliked about it
was the extra steps required upfront just to get a single page online.
I prefered CherryPy's object-publishing scheme for its sheer simplicity.
I think that simple mechanism, coupled with Routes for more complicated
stuff is the sweet spot in this area.

> The template and
> persistence mechanisms used have the principal advantage of just being
> there in the same package when compared with other solutions, and I
> don't think they'd have many fans if they were just some random
> projects available from the Python Package Index.

Perhaps, but I find the ORM and templates from Django inferior to other
projects, namely SQLAlchemy and Stan.  These two aspects of frameworks
seem to be the ones that generate the most passionate debate, probably
because they touch the spot the framework user spends most of his time
working in.  The bottom line is that if you don't like the ORM or the
template engine, you probably won't like the framework, even though they
are logically separate entities.

Also, I think TurboGears has demonstrated that it's quite possible to
paste together a lot of subprojects into a single uberproject and have
it succeed.  Not only has TurboGears succeeded, it's increased interest
in the various subprojects that it's composed of.

One project I'm keeping my eye on is Clever Harold which is taking the
most loosely-coupled approach to date, using WSGI to paste together all
the layers so you could conceivably replace every component in the
framework.  I haven't tried it yet, but it sounds interesting.

http://www.cleverharold.org/

> > TurboGears on the other hand did, and really, it helped clarify
> > a few things I had vague notions about.  I think we'll do better not
> > trying to shoehorn people into one or the other.
> 
> The goal is to provide appropriate solutions for particular problem
> cases, especially common cases like database-backed Web sites, rather
> than choosing something which only does a particular flavour of
> database-backed site and then claiming that it's a silver bullet. 
> I've written a number of Web applications for my own use, and many such
> applications either don't use a relational database or use it in a way
> that is completely orthogonal to some relatively simple
> object-relational scheme. Some of these applications are admittedly
> simple, but having to create various tables in relational databases as
> an offering to some framework deity is pure unnecessary overhead that
> should suggest, at least to the more objective among us, that any
> solution requiring such baggage is perhaps not always the most optimal.

I don't think any of the frameworks really require a database.  There
was some discussion of this exact topic on the TurboGears list a while
back, but I don't recall the outcome, but yes, I think there's a place
for all sorts of web frameworks, ranging from simple to Zope ;-)


Regards,
Cliff
--