Pros/Cons of Turbogears/Rails?

[kenneth.m.mcdonald]

First, I don't intend this to be a flame war, please. Python
and Ruby are the only two languages I'd willingly work in
(at least amongst common languages), and TurboGears and
Rails seem roughly equivalent.

I'm much more knowledgable about Python, but that's a minor
issue--I've been intending to learn more Ruby anyway.

Here are the pros and cons that I'm aware of and consider
important:

Turbogears:
+ SqlObject allows working with the DB tables without
using SQL itself.
+ Likely to be faster because as far as I'm aware, Python
is significantly faster.
+ Easy access to other libraries (such as the Python
Imaging Library) that Ruby, being a relatively newer
language, doesn't have equivalents to.
+ Built-in default SQLite makes it easier to set up?
(as far as I can tell, Ruby requires MySql by default--don't
know how easy this is to change.)
+ I find the templating system somewhat cleaner; code in
py: xml namespace allows pure .html templates, instead
of equivalent of .rhtml files.

Ruby:
+ More mature system. More stable? More features?
+ Much better documented. This is a biggie.
+ Built-in Rubydoc system would make documenting the
system easier. (IMHO, developers almost always
underestimate the need for good documentation that
is written along withe the system.) Is there a
Python doc system that has received Guido's blessing
yet? D'oxygen would seem an obvious choice.
+ Better coordination with Javascript helper code?

I was initially leaning towards Rails due to maturity,
but the most recent version of TurboGears seem to have
fixed a lot of the "ad hoc" feeling I got from previous
versions. But I'm still very much up in the air.

Thanks,
Ken

P.S. If I wanted to provide an image by streaming the
file data directly over the connection, rather than by
referring to an image file, how would I do that? I'd
like to build code that would allow images to be assembled
into a single-file photo album (zip or bsddb file), and
so can't refer to them as individual image files.

[Adam Jones]

Bruno Desthuilliers wrote:

Paul Boddie wrote:

Ray wrote:

(snip)

We're a Java shop so
our developers are trained in Java, Struts, Tomcat, etc. Any switch to
a dynamic language will be a huge change. However it baffles me that
they are open to at least a PoC in Rails. but when I suggested Python,
they went: "nah we're not interested in Python. Rails it is."

*shrugs* whatever it is, those guys are doing something right.

Making the Java people feel like they're doing something wrong, I
guess. And perhaps the Rails people realised that by giving those
people who lack direction, motivation, conviction or a sense of purpose
or control something to gravitate towards, some of them might feel
empowered enough to evangelise their discovery to the rest of the
group.

FWIW, and while it's certainly not enough by itself to explain the
phenomenon, I think that Ruby's object model being much more
conventional than Python's may have some influence too on RoR's adoption
by the Java world.

I don't know enough about Ruby to comment, but how is its object model
"more conventional" than Python's? The only thing I can see is access
control for methods, which seems like a silly thing to base a language
decision on.

>

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Bruno Desthuilliers]

Adam Jones wrote:

Bruno Desthuilliers wrote:

>Paul Boddie wrote:

>>Ray wrote:

(snip)

>>>We're a Java shop so
our developers are trained in Java, Struts, Tomcat, etc. Any switch to
a dynamic language will be a huge change. However it baffles me that
they are open to at least a PoC in Rails. but when I suggested Python,
they went: "nah we're not interested in Python. Rails it is."

*shrugs* whatever it is, those guys are doing something right.
Making the Java people feel like they're doing something wrong, I
guess. And perhaps the Rails people realised that by giving those
people who lack direction, motivation, conviction or a sense of purpose
or control something to gravitate towards, some of them might feel
empowered enough to evangelise their discovery to the rest of the
group.

FWIW, and while it's certainly not enough by itself to explain the
phenomenon, I think that Ruby's object model being much more
conventional than Python's may have some influence too on RoR's adoption
by the Java world.

I don't know enough about Ruby to comment, but how is its object model
"more conventional" than Python's?

short answer (no time to elaborate...) and IMHO (of course):

Well, Ruby's object model is mostly based on Smalltalk, with private
attributes representing state, public methods representing behaviour,
and a "message passing" mechanism which will select the appropriate
method an call it.

In Python, an object is mostly a set of attributes, some of them
implementing the descriptor protocol, some of them being callables, and
one of them being the class object (which itself etc...). On top of
this, you have a lookup mechanism and a 'call' operator. And "message
passing" in fact boils down to retrieving an attribute (thru the lookup
mechanism, which can itself cause function/method calls, decorate the
attribute etc), and eventually apply the call operator to this attribute.

From the surface, the main visible differences are that Python has no
proper access restrictions and that one can retrieve a reference to a
method object via simple lookup, but the philosophy is really different
IMHO.

The only thing I can see is access
control for methods, which seems like a silly thing to base a language
decision on.

Java's philosophy is bondage and discipline. This has been sold over and
over to both suits and programmers. Making the move to a dynamically
typed language is already a big step for some of these peoples, so even
if all the difference they see is the absence of access control, I think
it can impact the choice. Now go tell them you can even change the class
of a given instance at runtime, and look at them running away screaming !-)

Not to say Ruby is less flexible or dynamic than Python (AFAICT, they
both have roughly equivalent potential in this domain), but Ruby can
surely look safer and way less confusing than Python to Java'ers.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Jaroslaw Zabiello]

ke************* ***@sbcglobal.n et wrote:

+ SqlObject allows working with the DB tables without
using SQL itself.

Rails has ActiveRecord ORM, which IMO has nicer and simpler
syntax than SQLObject. Rails has migrations, TB - not (Migrations is
versioning system for evolving database schema)

+ Likely to be faster because as far as I'm aware, Python
is significantly faster.

Python is maybe faster, but with YARM (which is not stable yet) Ruby
will be about 10x faster. YARM is full virtual machine like Java.

+ Easy access to other libraries (such as the Python
Imaging Library) that Ruby, being a relatively newer
language, doesn't have equivalents to.

Ruby is not so young you think. It became more popular
when Rails has appeared.

+ Built-in default SQLite makes it easier to set up?

What? :) YAML is much easier.

(as far as I can tell, Ruby requires MySql by default--don't
know how easy this is to change.)

Change in config/database.yml driver: mysql to any you want,
like db2, postgres, sqlserver, sqlite, firebird, oracle etc. You can
change
default settings as well. See: rails --help

+ I find the templating system somewhat cleaner; code in
py: xml namespace allows pure .html templates, instead
of equivalent of .rhtml files.

But rhtml is much more flexible because it can generate *any content*,
not only xml. But Rails has THREE template systems: rhtml (main), rxml
(for rss and xml generation) and rjs (for javascript and AJAX).

And last but not least, TG is based on poor, unstable and buggy
CherryPy server. We had huge problems with CherryPy. I think that
Django or Pylons are much better frameworks. IMO TG is no competition
for Rails at all. The only real competition is Django or Pylons.

--
Jaroslaw Zabiello
http://blog.zabiello.com

[Jorge Godoy]

"Jaroslaw Zabiello" <hi**********@g mail.comwrites:

ke************* ***@sbcglobal.n et wrote:

>+ SqlObject allows working with the DB tables without
using SQL itself.

Rails has ActiveRecord ORM, which IMO has nicer and simpler
syntax than SQLObject. Rails has migrations, TB - not (Migrations is
versioning system for evolving database schema)

TG supports SQL Alchemy as well. With SQL Alchemy I believe you'll have a
better experience than with Rails' ORM.

With regards to Migrations, SQL Object does support something like that, but
you have to explicitly code it and then you can run sqlobject-admin upgrade
(or the equivalente tg-admin sql upgrade, since it is a wrapper...).

But rhtml is much more flexible because it can generate *any content*,
not only xml. But Rails has THREE template systems: rhtml (main), rxml
(for rss and xml generation) and rjs (for javascript and AJAX).

Well, TG has a few templating systems... MarkUp, Kid, Cheetah, ZPT, and
others. You can choose the one that best fits your needs / brain. You can
even have multiple template systems used depending on what was requested for
the same controller...
Which one is better isn't of my concern. I've already tested then and decided
what I want to use. The best thing is try them and see what works. You don't
have to choose only one -- but you have to use one per project to make it less
messy ;-)

--
Jorge Godoy <jg****@gmail.c om>

[Adam Jones]

Jaroslaw Zabiello wrote:

ke************* ***@sbcglobal.n et wrote:

+ SqlObject allows working with the DB tables without
using SQL itself.

Rails has ActiveRecord ORM, which IMO has nicer and simpler
syntax than SQLObject. Rails has migrations, TB - not (Migrations is
versioning system for evolving database schema)

I don't really see TG sticking with SQLObject. In moving to SQLAlchemy
it would pick up not only a migration system but also a much more
flexible abstraction system due to the use of a Data Mapper pattern
instead of the Active Record pattern. There already is an
implementation of Active Record on top of that, so that benefit stays
as well.

>

+ Likely to be faster because as far as I'm aware, Python
is significantly faster.

Python is maybe faster, but with YARM (which is not stable yet) Ruby
will be about 10x faster. YARM is full virtual machine like Java.

I tried to check out information on this, but the only docs I found
that looked like what I wanted were written in japanese. Do you have
any links discussing the status of this project? Does it make any
breaking changes to the Ruby implementation that will have to be fixed?
Has the RoR project already agreed to port to this when it is stable?

>

+ Easy access to other libraries (such as the Python
Imaging Library) that Ruby, being a relatively newer
language, doesn't have equivalents to.

Ruby is not so young you think. It became more popular
when Rails has appeared.

Although that is true there are not as many libraries available for
Ruby as there are for Python. This will probably change as the language
gains popularity, but for right now it pays to look into library
support before considering anything else about the language.

>

+ I find the templating system somewhat cleaner; code in
py: xml namespace allows pure .html templates, instead
of equivalent of .rhtml files.

But rhtml is much more flexible because it can generate *any content*,
not only xml. But Rails has THREE template systems: rhtml (main), rxml
(for rss and xml generation) and rjs (for javascript and AJAX).

Kid can be used to generate xhtml, rss, xml, pretty much anything that
is xml-based. I have even seen it used to generate xul applications for
firefox. The only thing on your list that it doesn't do is javascript.
Personally I would rather learn one templating language that is able to
treat all of my xml as xml no matter what use it is put to.

>
And last but not least, TG is based on poor, unstable and buggy
CherryPy server. We had huge problems with CherryPy. I think that
Django or Pylons are much better frameworks. IMO TG is no competition
for Rails at all. The only real competition is Django or Pylons.

I have never had much in the way of problems with CherryPy. From what I
have heard the project has made a lot of improvements recently, so it
may have changed since you last took a look at it.

Actually that point right there is where I think TG is a lot more
competitive that you believe. When a new version of any of the
foundation projects comes out, or a better project to fill that
particular need, TG can absorb it in the next version. The TurboGears
developers can spend most of their time working on additional code that
makes the project more useful instead of bug fixes and minor feature
upgrades to the core components. This philosophy is proven to work for
most other open source projects, and I have yet to hear a good argument
why it would not be successful for a web framework.

-Adam

[Christophe]

Jaroslaw Zabiello a écrit :

Python is maybe faster, but with YARM (which is not stable yet) Ruby
will be about 10x faster. YARM is full virtual machine like Java.

Google doesn't find YARM and so, YARM does not exist. Care to provide an
URL or something?

[fuzzylollipop]

Paul Boddie wrote:

fuzzylollipop wrote:

uh, no, Python predates Ruby by a good bit
Rails might be "older" than Turbogears but it still JUST went 1.0
officially.
It can't be called "mature' by any defintition.

Version numbers are a fairly useless general metric of project
maturity, taken in isolation.

But 1.0 releases do mean something, it means the DEVELOPER of the
package things it is just now ready for general consumption. That means
something regardless of what the number is.
Matter of fact, all major version releaese mean that, it is generally
understood thing. x.0 means this is now ready for non-beta general use.

[Lawrence Oluyede]

Christophe <ch************ *@free.frwrote:

Google doesn't find YARM and so, YARM does not exist. Care to provide an
URL or something?

it's YARV - http://www.atdot.net/yarv/

--
Lawrence - http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

[fuzzylollipop]

Ray wrote:

fuzzylollipop wrote:

uh, no, Python predates Ruby by a good bit
Rails might be "older" than Turbogears but it still JUST went 1.0
officially.
It can't be called "mature' by any defintition.

But at least in most developers' perception ... <snip>

nobody is talking about perception

[Paul Boddie]

fuzzylollipop wrote:

Paul Boddie wrote:

fuzzylollipop wrote:
uh, no, Python predates Ruby by a good bit
Rails might be "older" than Turbogears but it still JUST went 1.0
officially.
It can't be called "mature' by any defintition.

Version numbers are a fairly useless general metric of project
maturity, taken in isolation.

But 1.0 releases do mean something, it means the DEVELOPER of the
package things it is just now ready for general consumption. That means
something regardless of what the number is.

In various open source circles, the mere usage of 1.0 may indicate some
kind of stability, but not necessarily maturity, or at least the desire
of the developers to persuade users that the code is ready for them to
use. Consequently, there are numerous stable packages at 0.x because
the developers don't think they're near finished (ie. have produced a
mature system), numerous unstable packages at 1.x because the
developers want their 15 minutes of fame (GNOME 1.0 was apparently a
good example of this), and various packages at 3.x or 4.x that would
suggest a legacy of decades when they've probably only been in
existence for eighteen months at the most.

Matter of fact, all major version releaese mean that, it is generally
understood thing. x.0 means this is now ready for non-beta general use.

Agreed. Still, let's take some examples from the python.org Wiki's
WebFrameworks page to illustrate what I mean:

SkunkWeb (3.4.0), Zope (2.9.4 and 3.2.1), Plone (2.5), Karrigell (2.3),
CherryPy (2.2.1), Spyce (2.1), QP (1.8), Cymbeline (1.3.1), Django
(0.95), Webware (0.9.1), Pylons (0.9.1), TurboGears (0.8.9), PyLucid
(v0.7.0RC4), Paste (0.4.1), web.py (.138)

Now, just over half of the above have presumably passed some stability
threshold, and we could possibly even estimate the age of many of the
frameworks based on how high their version numbers are. However, note
that whilst Zope 3.2.1 is now presumably considered stable, something
like Zope 3.0 couldn't really be considered as mature as Zope 2.8 or
2.9 purely because of the nature of the code: a rewrite of the
architecture which, even if considered stable, cannot be considered
mature in comparison to its established predecessors with all the
accumulated expertise and experience associated with them.

Such comparisons of unequal things having the same name have also
affected projects like CherryPy, where 1.x and 2.x were apparently
quite different, and whilst CherryPy is currently at 2.2.1 and used by
other projects, it is described as unstable elsewhere in this thread -
contradicting various reports of successful large scale deployments, I
might add. Meanwhile, the original framework upstart, Webware, hasn't
even reached 1.0, yet it has been around for longer than many of the
others, whilst Pylons bears an identical version number.

Part of the difficulty in maintaining an overview such as the
WebFrameworks page arises from attempting to measure maturity,
stability, vitality and quality - something which some repositories
like Freshmeat attempt to tackle using various methods of measurement.
And as I was editing the version numbers recently, I did consider the
issue of whether they provided a reasonable impression of project
stability and/or maturity, but I rather feel that more considered
evaluations are the only way to get that kind of information.

Paul