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]

(e-mail address removed) 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]

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]

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]

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]

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]

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

 

[Paul Boddie]

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

 

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

 

[Sam Smoot]

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)
http://www.bigbold.com/snippets/tags/rails (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.

 

[Adam Jones]

In my understanding, which relies completely on the judgements of
co-workers regarding the rails side of the debate, TurboGears is more
flexible. Tasks which fall inside the scope of Rails' "opinion" are
probably easier there, but anything outside of what Rails was built to
do is harder than equivalent deviations from TurboGears. Obviously this
amounts to little more than hearsay, but nonetheless I think it is an
important element to look into.

I can say that each of them has their own genius decisions, and neither
is so lacking in documentation or community support to preclude
choosing either framework based on how well it suits your project.

 

[Ray]

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

 

[Jorge Vargas]

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.

yes and SQLAlchemy lets you do more complex things, like working with
an existing database.

+ Likely to be faster because as far as I'm aware, Python
is significantly faster. no idea there.
+ Easy access to other libraries (such as the Python
Imaging Library) that Ruby, being a relatively newer
language, doesn't have equivalents to.

python's'lib is MUCH more bigger

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

actually no you still have to install sqlite and the "build in" is
just a config entry.

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

not at all, you could say that in a TG vrs django or zope.

+ Much better documented. This is a biggie.

TG docs are lacking at the moment mainly due to a problem with the
documentation engine, we have been bouncing between trac,docudo, xmls
and now moinmoin. this will be settle soon, until this is fix there
will be on 1.0 (which may be the reason why RoR is already out and TG
isn't)

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

huh? docstrings ...

+ Better coordination with Javascript helper code?

again huh, in TG you include a JS lib and it's done. if someone has
made a widget for it all you have to do is install it (easy_install
widget).

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.

is that 0.5 and 0.8? almost everyone on TG runs the 0.9 alpha's there
has been so much code in to them that is stable as a rock.

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.

if that's the case either is just overkill all you need is a simple
httpserver and reading a bit about image encoding.

 

[Steve Holden]

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

Also remember that there are still lots of Python users who keep the
fact quiet because they regard it as a strategic advantage. They don't
*want* Python usage to spread, or they'll lose their advantage.

regards
Steve

 

[Paul Boddie]

[comp.lang.ruby snipped]

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

Yes, I saw this with Java several years ago. However, as someone
actually using the technology concerned, it's obviously vital to make
the distinction between actual and perceived maturity. My impression is
that we're seeing developers, not managers, failing to make that
distinction.

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.

This sentiment somehow reminds me of various Oracle products.

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

Sure. Just get certified on whatever today's middle management are
advocating, spend a few years working with that stuff, then repeat the
process for the next generation of middle management - it can certainly
make money for people who don't seek any meaning in what they do.

[...]

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

Python has had its share of the spotlight: Eric Raymond's advocacy
dates back to the late 1990s; Bruce Eckel still advocates Python but
started doing so a few years ago. Perhaps the latest arrivals to the
party (celebrating dynamic languages in this case) are usually the
loudest, in order to make up for their sluggish realisation that Java
isn't the panacea they insisted it was while it was still the cool new
thing. Or perhaps a lot of these people do quite nicely out of surfing
whatever trend currently is the cool new thing.

And, since when do hard facts matter anyway?

When certain individuals claim that more Java people know about Ruby
than they do about Python. I know that there are people out there who
know (about) Java but not about Jython, for example, but even in
circles where buzz and hype seem like everything (eg. marketing) the
hard facts or statistics are still critical because they actually help
those people do their job properly. Moreover, just stating something
doesn't make it true - the hard facts serve to prove or disprove such
assertions, and to anyone serious about understanding the underlying
phenomena, it's vital to seek those facts out.

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

So why don't they? Management pressure? Why don't people write more
Python in their day job? Any suggestions?

Paul

 

[Christophe]

Paul Boddie a écrit :

[comp.lang.ruby snipped]

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

So why don't they? Management pressure? Why don't people write more
Python in their day job? Any suggestions?

Probably because of the extreme Bondange And Disciplineness of Eiffel,
the incredible cost of each user license, lack of generic programing (
you know, the thing easy to do in Python/Ruby but requires templates in
C++ ) and the complete lack of a correct debugger.

By now, it seems that some of those problems have been fixed in various
ways but we now have even better : incompatible implementations of the
language!

Eiffel is for all purposes a niche language only used by some fanatics
here and there

 

[Ray]

Paul Boddie wrote:

Sure. Just get certified on whatever today's middle management are
advocating, spend a few years working with that stuff, then repeat the
process for the next generation of middle management - it can certainly
make money for people who don't seek any meaning in what they do.

It can certainly make money--true. "Don't seek any meaning in what they
do"?! You're just accusing a lot of honest hardworking people to be
mindless drones there. We have feelings too, you know

Python has had its share of the spotlight: Eric Raymond's advocacy
dates back to the late 1990s; Bruce Eckel still advocates Python but
started doing so a few years ago. Perhaps the latest arrivals to the
party (celebrating dynamic languages in this case) are usually the
loudest, in order to make up for their sluggish realisation that Java
isn't the panacea they insisted it was while it was still the cool new
thing. Or perhaps a lot of these people do quite nicely out of surfing
whatever trend currently is the cool new thing.

Perhaps that is true. A pity though, personally I tried to learn Ruby
but it just doesn't go well with my brain.

When certain individuals claim that more Java people know about Ruby
than they do about Python.

First, that question was supposed to be rhetorical Second, my claim
is not that general. Certainly proving such a general claim is an
enormous undertaking. It just happens that most of Java developers I
know, and I know quite a lot since I've been doing this for years, they
know Ruby and Rails. Python, Django, Turbogears, make them go "huh?".
I've heard of one entrepreneurial guy starting an exclusively RoR shop
and doing quite well at it. I haven't heard a Django/Turbogears shop
yet.

I know that there are people out there who
know (about) Java but not about Jython, for example, but even in
circles where buzz and hype seem like everything (eg. marketing) the
hard facts or statistics are still critical because they actually help
those people do their job properly. Moreover, just stating something
doesn't make it true - the hard facts serve to prove or disprove such
assertions, and to anyone serious about understanding the underlying
phenomena, it's vital to seek those facts out.

True. But since when do hard facts matter? That is, it's not that I
haven't tried to make people know how great Python is. but I can talk
until I'm blue in the face and they just go, "nah". What I'm saying is
that people (and management) unfortunately are sold to not with hard
facts, but with whatever that X viral factor is. And for some reason
the RoR crowd has managed to make it quite viral.

So why don't they? Management pressure? Why don't people write more
Python in their day job? Any suggestions?

Well, I posted in this group a few weeks ago because I was trying to
convince the managers to give Python a try and was looking for
additional ammo. In the end Django is out because of its lack of
support for Oracle. But it's a catch 22 isn't it? 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.

 

[Paul Boddie]

It can certainly make money--true. "Don't seek any meaning in what they
do"?! You're just accusing a lot of honest hardworking people to be
mindless drones there. We have feelings too, you know

Well, I'm sorry for the unintentional insult. However, I've come to
believe that some people have the personality traits that let them
tolerate redoing the same work over and over again for no reason other
than management "furniture rearranging", whereas others start to resent
having their (working) life repeatedly flashed before their eyes, but
in slightly different colours, over a longer period of time. If there's
some kind of art that somehow increases tolerance of such things in a
humane way, I'd be interested to know what it is.

[...]

Well, I posted in this group a few weeks ago because I was trying to
convince the managers to give Python a try and was looking for
additional ammo. In the end Django is out because of its lack of
support for Oracle. But it's a catch 22 isn't it?

In the end, provided you have the time and energy (or money) for it,
you just have to make your own plan for bridging whatever gap there is
in the functionality of whatever open source project you intend to
employ professionally. I was once in a similar situation myself, with
Oracle products as well, where I had to put in the work myself to get
the necessary support needed for having my Python plus Oracle code
working in an environment that was Python-sceptical at best. I guess
the code was ultimately taken out of production, and everyone went over
to a pure Java strategy, but you can't always infuence people by
lobbying.

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.

Paul

 

[Bruno Desthuilliers]

Ray wrote: (snip)

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.