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.

[fuzzylollipop]

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

Looks like you mixing comparisons.

Ruby:
+ More mature system. More stable? More features?

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.

+ Much better documented. This is a biggie.

Rails has no documentation, period. The authors acknowledge this
openly.

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

Pydoc IS standard. This has been around for a long time.

+ Better coordination with Javascript helper code?

Again, is this a Python vs Ruby or Turbogears vs Rails post, you seem
highly confused on the distinctions between language vs framework.

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.

again, Ruby can't be considered 'mature' by any definition.

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.

??????

[Ray]

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, it is (not necessarily in
the absolute sense, but perhaps relative to Django or Turbogears).
Mind, it doesn't even need to be true, we're talking of perception
here. Also, I'm not talking about only Python and/or Ruby developers
here, I'm talking about developers in general, a huge bunch of which
comes from Java/.NET background.

I know many of them and a lot of them do know Rails. When you say
Turbogears or Django, however, they go, "what?".

Sadly, there are more Java guys who know about Ruby than Python,
despite the fact that Python predates Ruby by quite a few years...
(this must be that Bruce Tate dude's fault! )
<snip>

[Robert Kern]

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, it is (not necessarily in
the absolute sense, but perhaps relative to Django or Turbogears).
Mind, it doesn't even need to be true, we're talking of perception
here.

You might be. No one else in the thread is.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Ray]

Robert Kern wrote:

You might be. No one else in the thread is.

What are you saying? That my perception that RoR is mature is wrong? I
never even said that was mine. That was what I got from talking to a
lot of developers whose main language is neither Python nor Ruby, while
I was trying to introduce Python to them. I've always been enthusiastic
about Python and think it'd be nice for a change to be able to work
with it in a project at work instead of at home.

And yes, no one else in this thread, which consists of 6 posts so far,
says so, so how is it even relevant to how other developers perceive
RoR in comparison with Django or Turbogears? You're not making any
sense here.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Robert Kern]

Ray wrote:

Robert Kern wrote:

>You might be. No one else in the thread is.

What are you saying? That my perception that RoR is mature is wrong?

No, that the part of your message that I quoted was wrong. Specifically, "we're
talking of perception here." No one else here is talking about the perception of
maturity but claims about the actual maturity.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[Bruno Desthuilliers]

Ray wrote:
(snip)

Sadly, there are more Java guys who know about Ruby than Python,
despite the fact that Python predates Ruby by quite a few years...

FWIW, Python is somewhat older than Java too...
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Bruno Desthuilliers]

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

First, I don't intend this to be a flame war, please.

Then avoid crossposting to both c.l.ruby and c.l.python !-)
(BTW, fu2 c.l.python).

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.

I personnaly don't like SqlObject. SqlAlchemy looks like a much better
solution IMHO. And FWIW, Ruby has it's own ORM too.

(snip)

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.

Then take a few days to play with both Rails and TG and go with the one
that better fits your brain.

FWIW, you may also want to check Pylons (another Python Web-MVC framework).

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

[Paul Boddie]

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.

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

But at least in most developers' perception, it is (not necessarily in
the absolute sense, but perhaps relative to Django or Turbogears).
Mind, it doesn't even need to be true, we're talking of perception
here.

So actual maturity isn't important when using a technology: it's
"perceived maturity" that counts, right? Any continuation down that
particular path of reasoning surely leads you to the point where you
claim, in concert with the developers, that increasing levels of
inconvenience caused by gratuitous changes or broken documentation is
not caused by bugs or general immaturity but by "features". I guess
this is the definition of "opinionate d software" that some people are
so excited about.

[...]

Sadly, there are more Java guys who know about Ruby than Python,
despite the fact that Python predates Ruby by quite a few years...
(this must be that Bruce Tate dude's fault! )

If you only listen to Bruce Tate et al, I imagine you could have the
above impression, but I'd be interested to see hard facts to back up
those assertions.

Paul

[gregarican]

As I read in another post on this thread, do some initial scoping out
of either framework and pick the one that seems to suit your way of
thinking/coding the best. If you scan over some sample code on the
projects' websites you should get a basic idea of what they will be
like.

Although a bit more obscure than the two frameworks you are
considering, have you checked out Seaside (http://seaside.st)? It's a
Smalltalk framework that interests me personally. I've had the
opportunity to check it out briefly, but haven't had a chance to
actually mock up an app using it. If you check it out as well as a neat
AJAX library that can overlay it called Scriptaculous
(http://script.aculo.us) you can do some pretty slick things concisely.
I doubt that something like this will immediately skyrocket to the top
of the commercial developer's hit list, but it is something that I
would play around with since it will only expand my knowledge base. And
I can have fun while doing it :-)

Out of what I've seen working with Rails and checking out TurboGears I
chose Rails since it fit in with my way of thinking the best. Everyone
has their own taste so I wouldn't take any one person's (or one
group's) opinion. Read up on them a bit and see which one looks the
most interesting to you.

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

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.