Pros/Cons of Turbogears/Rails?

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

Huh? You might not like the documentation, but it's actually quite
substantial, especially for so new a framework. Don't be telling
people stuff like this that is blatantly untrue.

Take a look at MasterView:

   http://masterview.org/

To quote its own web site:

  MasterView is a ruby/rails optimized HTML/XHTML friendly template engine.
  It is designed to use the full power and productivity of rails
including layouts,
  partials, and rails html helpers while still being editable/styleable in a
  WYSIWYG HTML editor.

Curt

···

On 8/27/06, James Edward Gray II <james@grayproductions.net> wrote:

On Aug 27, 2006, at 3:10 PM, kenneth.m.mcdonald@sbcglobal.net wrote:

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

Just FYI, rhtml files are just one way to build output with Rails.
You might want to look at using Builder, which is a pure Ruby interface.

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>

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.

Wow that's a lot of FUD, especially since you're beating up on Rails
for it's docs and maturity, when I doubt (but couldn't prove)
turbogears comes close.

Lets be specific:

12/13/05: http://dev.rubyonrails.org/changeset/3303

It can't be called "mature' by any defintition.

It's easy to deploy a site without running into bugs as long as you're
not dealing with any edge-cases. As far as OSS solutions go, that
pretty well fits my definition of "mature". So there's one.

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

Why you would just talk out of your ass like this escapes me.

http://api.rubyonrails.org (Look at any of the :Base classes for
overviews)
http://rubydoc.org (For basic Ruby help)
http://rails.techno-weenie.net/ (Help with the lesser known areas of
RoR, and tips & tricks)
BigBold - Informasi Tentang Bisnis dan Marketing (Snippets other people have
found useful)
http://wiki.rubyonrails.com/rails/pages/Howtos (Lots of "Getting
Started" type how-tos)
http://caboo.se (A blog aggregation of some of the committer's )

Then again, you could just google for "rails documentation" (here's a
link:
http://www.google.com/search?client=safari&rls=en&q=rails+documentation&ie=UTF-8&oe=UTF-8
)

And the top link will take you to a page on the Wiki that describes all
of this. Until you want to start writing plugins and such, this
documentation pretty much fits the bill. Could there be more? Yes. Is
it perfect? Obviously not. Is finding documentation going to be a
problem for anyone willing to spend a few minutes with Google or on IRC
asking questions if you're genuinely trying? I seriously doubt it.

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

It seems like you're the one confusing things now. Ruby is obviously a
pretty mature language. There are definite feature holes (encoding
aware Strings, native Threads), but the community, documentation,
tutorials (by far the best of any language I've learned), are all
pretty mature.

Is Rails mature? Compared to JSP? Probably not... compared to
TurboGears? (The entire point of this topic, which you conveniently
side-step by managing to not mention it once) Easily.

So if you decide to reply, might I suggest spending a few minutes with
Google to get your facts straight next time? Oh, and keeping an eye on
the actual topic might be a good idea too.

Sam Smoot wrote:

http://rubydoc.org (For basic Ruby help)

It's http://ruby-doc.org

You need that hyphen.

···

--
James Britt

"Blanket statements are over-rated"

I ran the YARV benchmarks and several of them showed a 10x or more
speedup, though for many others it was 2-3x. I guess anyone who
really needs to know how much faster YARV will run their code should
just profile it and see rather than try to figure it out in advance.

Jeremy Henty

···

On 2006-08-31, James Edward Gray II <james@grayproductions.net> wrote:

I'm not sure what makes you say it's "10x faster," but that sounds a
little high to me. My recent playing with the VM showed a little
over a 2x increase in speed, for the code I was running.

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.

What is the advantage of Data Mapper? I cannot find..

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.

We have created two quite big sites in CheerryPy in past and we have many
issues with its bad implementation. Sessions were useless, forks were
removed from early code without any warning. Maybe now it is better, but I
have lost any confidence in CherryPy quality.

···

On 31 Aug 2006 08:24:29 -0700, Adam Jones wrote:

--
Jarosław Zabiełło
http://blog.zabiello.com

Hi all,

I ran the YARV's benchmarks and got an 5x increase in speed[1]. Anyway, those
tests are far away from real production code.

See ya!

[1] banot.net

···

El Jueves, 31 de Agosto de 2006 15:41, James Edward Gray II escribió:

On Aug 31, 2006, at 9:30 AM, Jaroslaw Zabiello wrote:
> kenneth.m.mcdonald@sbcglobal.net wrote:
>> + 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.

The name of the virtual machine that runs Ruby 1.9 and up, is YARV
(not YARM).

I'm not sure what makes you say it's "10x faster," but that sounds a
little high to me. My recent playing with the VM showed a little
over a 2x increase in speed, for the code I was running. This was a
very unscientific test for sure, but it *may* be a little closer to
the average speed increase people are likely to see.

--
_o) Imobach González Sosa
//\ email: imobachgs at banot dot net
V_/_ jid: osoh at jabberes dot org
url: banot.net - banot Resources and Information.
blog: http://devnull.blogs.banot.net

--
_o) Imobach González Sosa
//\ email: imobachgs at banot dot net
V_/_ jid: osoh at jabberes dot org
url: banot.net - banot Resources and Information.
blog: http://devnull.blogs.banot.net

Sam Smoot wrote:
big rant snipped since Google Groups has what I responding to:

So if you decide to reply, might I suggest spending a few minutes with
Google to get your facts straight next time? Oh, and keeping an eye on
the actual topic might be a good idea too.

I got my facts straight, Ruby is not tested in production environments.
And I am speaking from a BIG internet site scale. Apache is mature,
there is a definition of mature tested in the wild in production, and
you qualified your opinion by excluding edge cases, the internet is
NOTHING BUT EDGE CASES. Just look at the SMTP and HTTP RFC's they are
nothing but edge cases.

And read the entire thread, I am the one that specifically stated that
the original poster was confused on what he was asking about. Let me
make it really clear. Neither Ruby NOR Rails is "mature" by ANY
REASONABLE definition.

fuzzylollipop wrote:

I got my facts straight, Ruby is not tested in production environments.

That's odd... it's running bank websites, credit-card processing, high
traffic sites like ODEO and Penny-Arcade. Seems pretty "production" to
me.

And I am speaking from a BIG internet site scale.

Yes yes, I'm sure that never fails to impress the ladies.

The internet is NOTHING BUT EDGE CASES.

I beg to differ. Step outside of the Top 1000 and the web is largely
marketing, portfolio, reporting, and boring administration sites.

Neither Ruby NOR Rails is "mature" by ANY REASONABLE definition.

Companies and individuals are using it to competitive advantage every
day. Obviously you don't have much (if any) actual experience with Ruby
OR Rails.

By the way, we've yet to hear your opinion on Python and TurboGears...

By the way, we've yet to hear your opinion on Python and TurboGears...

Don't bother... it's probably not mature: how many 13-year-olds do you
know that are? :wink: Maybe we should just stick to assembly, because
that's seriously the only thing that is fast and mature.

Oh wait... hell no.

Anyways, I want to take this opportunity to refocus the discussion on
_relative_ maturity: I believe the OP was asking about which of the
_TWO_ options were more mature, Ruby/Rails or Python/TurboGears.

fuzzylollipop: you might want to get the fuzz off your lollipop and
realize that if the internet is nothing but edge cases, that means
that the internet _has_ no edge cases. That's how edge cases work:
they are the unusual, highly selective cases, on the edge of
everything else. And, yes, I'd dare say that Ruby would be a great
option for most of the non-edge cases, and even a good deal of the
edge cases too!

So stick that fuzz on your lollipop and suck it :wink:

M.T.

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.

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! )

Well, sorry, we were responding to Ken who acknowledges both Ruby and
Python (even claiming his proficiency in Python) as the only options
he's considering for the job. Which means, implicitly, that we can
narrow our scope to just these two platforms/frameworks.

:smiley:

M.T.

I think the original poster is getting Rails and Ruby confused a fair
amount. To be clear, Ruby is a language like Python. Rails is a
framework for writing web applications like Django.

I have no experience with TurboGears so the best I can do is try to
help explain some of your ideas about Rails.

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

Although migrations have already been mentioned, I think you're
referring to something like ActiveRecord in Rails with is an object
mapping of table rows. Yes, Rails has it. I don't really write SQL
anymore.

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

I'm not sure about the benchmarks between Python and Ruby but Rails is
plenty fast as long as it is deployed appropriately. I'd expect the
same from TurboGears and expect them to be capable of similar results.

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

Python isn't that much older than Ruby. Check in on the libraries you
need before deciding based on this. It hasn't been a problem for me
thusfar.

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

Ruby certainly doesn't require MySQL. Rails configures for MySQL by
default but it's trivial to change. If you know your'e going to use
sqlite instead you can even do 'rails my_project -d sqlite' and it'll
do it for you.

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

I'm not sure what you mean. If you don't like ERb there are several
alternatives.

I'd say try both out and work with what feels more natural. This will
also give you a chance to see what you're missing in each.

···

--
Kevin Clark
http://glu.ttono.us

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 "opinionated 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

Paul Boddie wrote:

> 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?

Well depends on "counts" in what sense. Counts as in the managers up
there perceive something as mature, despite proofs of the contrary,
certainly "counts", because then we'll end up having to work with a
probably immature technology (nothing about RoR here, I'm talking in
general). Yet with more people using it, its actual maturity will
inevitably rise as well, maybe eventually to a level near that of its
perceived maturity.

"Counts" as in to us developers who are actually spending our lives
doing this? Perhaps yes too. If you're well-versed in something that is
widely perceived to be mature, you may find it easier to win bread for
your family, even if you have a painful time using it.

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 "opinionated 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.

Yeah, see, the thing is that Python is not lacking luminaries endorsing
it either, e.g.: Eric Raymond and Bruce Eckel. But for some reason this
"Python is good" meme is not that viral. I wonder why...

And, since when do hard facts matter anyway? I've met a number of
people who've told me they'd program in Eiffel if they could. And hey,
perhaps in its day Eiffel *was* the best OO language out there.
Certainly it looked cleaner than C++! :slight_smile:

···

Paul

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.

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

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 wrote:

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.

nope in GENERAL usage, 1.x means that the developer is designating a
version that is feature complete and stable. I never ever mentioned
comparing version numbers between differing packages.

MY POINT was the developers of Rails JUST RECENTLY decided that it was
ready for general consumption compared to all the PREVIOUS Rails
releases.

And NONE of these frameworks has been used to power anything along the
scale of what I work with on a daily basis.

And speaking from experience, autogenerated "Active Object Pattern"
frameworks dont' scale. And Rails is no exception. It didn't work 10
years ago when all the ORM vendors were selling ridiculously price
"point and click" database application builders, what makes people
think it will now?

<...>

MY POINT was the developers of Rails JUST RECENTLY decided that it was
ready for general consumption compared to all the PREVIOUS Rails
releases.

<...>

Another point is that Rails were EXTRACTED from WORKING application, namely
Basecamp :wink:

Regards,
Rimantas

···

--
http://rimantas.com/