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.
42  3804  ke****************@sbcglobal.net 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.
??????
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>
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
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
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
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('@')])" ke****************@sbcglobal.net 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('@')])"
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
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.net 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.
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) 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=...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.
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.
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++! :)
Paul
On 8/27/06, ke****************@sbcglobal.net
<ke****************@sbcglobal.netwrote:
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.
--
http://mail.python.org/mailman/listinfo/python-list
Ray wrote:
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++! :)
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
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
[comp.lang.ruby snipped]
Ray wrote:
Paul Boddie wrote:
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).
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.
[...]
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...
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
Paul Boddie a écrit :
[comp.lang.ruby snipped]
Ray wrote:
>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 :)
Paul Boddie wrote:
<snip>
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 :(
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.
Perhaps that is true. A pity though, personally I tried to learn Ruby
but it just doesn't go well with my brain.
And, since when do hard facts matter anyway?
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.
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?
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
Ray wrote:
>
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
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.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
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('@')])"
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('@')])" ke****************@sbcglobal.net 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
"Jaroslaw Zabiello" <hi**********@gmail.comwrites: ke****************@sbcglobal.net 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.com>
Jaroslaw Zabiello wrote:
ke****************@sbcglobal.net 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
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?
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.
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
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
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
On Thu, 31 Aug 2006 11:42:47 -0300, Jorge Godoy wrote:
TG supports SQL Alchemy as well. With SQL Alchemy I believe you'll have a
better experience than with Rails' ORM.
I would not be so sure. I have tried to work with SQL Alchemy (using
Pylons) and I have been disappointed. :( It's syntax for selects is ugly
and not intuitive. Django ORM looks much better. SQLAlchemy has to be added
to Django as alternative ORM but *without breaking* current, clean API: http://groups.google.com/group/djang...77bb34cfde1ec7
>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.
This is another topic. Rails can also use another third-party template
system (like Liquid which was inspired by Django). For me using many,
different template systems *for the same task* make no sense. Rails uses
three templates, but for *different tasks*. Its RJS is perfect for AJAX.
Really cool, simple, and almost no javascript is required. Just clean Ruby
for everything.
--
Jaros³aw Zabie³³o http://blog.zabiello.com
On 31 Aug 2006 08:24:29 -0700, Adam Jones wrote:
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.
--
Jaros³aw Zabie³³o http://blog.zabiello.com
On 31 Aug 2006 08:24:29 -0700, Adam Jones <aj*****@gmail.comwrote:
>
Jaroslaw Zabiello wrote:
ke****************@sbcglobal.net 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.
yes indeed as someone said earlier the support is already there and
all that needs to be done is a migration path.
+ 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.
either that or all the hipy of RoR will go away.
+ 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 for javascript you have mochikit which is really nice.
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.
I believe that is the most important part of TG, taking the best of
the best, and letting the framework adapt and morphe.
for example noone plan to move to SA, 0.1 came out a couple of people
took and look and like it, then 0.2 was "mature enough" so people
started thinking about the migration. after that some code was made
and now we have TG with SA, eventually it will be the default.
Same with templates, kid is really weak at generating non-xml, it has
a plain text serializer but the input must be xml so that's overkill.
So a new template frontend (chettah was born).
Someone ones said on the mailing list TG is the Ubuntu of web
frameworks, and I think I'll add and you can strip down the kernel and
it wont break :)
-Adam
--
http://mail.python.org/mailman/listinfo/python-list
On 8/31/06, Jorge Vargas <jo**********@gmail.comwrote:
On 31 Aug 2006 08:24:29 -0700, Adam Jones <aj*****@gmail.comwrote:
I believe that is the most important part of TG, taking the best of
the best, and letting the framework adapt and morphe.
for example noone plan to move to SA, 0.1 came out a couple of people
took and look and like it, then 0.2 was "mature enough" so people
started thinking about the migration. after that some code was made
and now we have TG with SA, eventually it will be the default.
Same with templates, kid is really weak at generating non-xml, it has
a plain text serializer but the input must be xml so that's overkill.
So a new template frontend (chettah was born).
Someone ones said on the mailing list TG is the Ubuntu of web
frameworks, and I think I'll add and you can strip down the kernel and
it wont break :)
But that is not really true. If you use Cheetah instead of Kid, you
lose out: No widgets, no auto-generated code and the (incomplete)
documentation won't apply anymore (it assumes Kid templates ofcourse).
If you use SQLAlchemy instead of SQLObject, no identity framework, no
administrative tools (tg-admin sql, CatWalk etc) and no documentation.
If you use prototype instead of MochiKit... I have no idea what
happens and using another webserver than CherryPy isn't possible right
now, I guess?
In fact, if you decide to replace so many modules that TurboGears
depend on, what do you gain in using TurboGears at all? It seems like
the TurboGears developers have a lot of work to do, (and a lot of
documentation to write) if they want to make their framework as easy
to use as others (ie: Django) that takes a more holistic approach.
TurboGears more seem to be like emacs than Ubuntu - infinitely
customizable...
In the future both Rails and TurboGears will probably be great. But
since someone mentioned Rails moving to YARV, and TurboGears moving to
SQLAlchemy and Markup, it seems to me that they are both in a state of
flux and not quite ready yet.
--
mvh Björn
On Thu, 2006-08-31 at 23:31 +0200, BJörn Lindqvist wrote:
On 8/31/06, Jorge Vargas <jo**********@gmail.comwrote:
On 31 Aug 2006 08:24:29 -0700, Adam Jones <aj*****@gmail.comwrote:
Someone ones said on the mailing list TG is the Ubuntu of web
frameworks, and I think I'll add and you can strip down the kernel and
it wont break :)
But that is not really true. If you use Cheetah instead of Kid, you
lose out: No widgets,
Untrue. Even though I don't use widgets much myself, I wanted to make
sure they *could* be used with TurboStan, so I did a quick test with
Kevin's autocomplete widget. Worked fine. I can't see why Cheetah
would be any different.
no auto-generated code
What auto-generated code? The example templates that you get with
quickstart? Hardly a loss.
and the (incomplete)
documentation won't apply anymore (it assumes Kid templates ofcourse).
True. However I've had little trouble translating from Kid to Stan (and
that's probably a longer jump than from Kid to Cheetah).
If you use SQLAlchemy instead of SQLObject, no identity framework,
Completely false.
no administrative tools (tg-admin sql,
True.
CatWalk etc
True.
) and no documentation.
Partially true. The documentation exists but some of it is out-of-date
and it was never very complete to begin with. Of course, like many OSS
projects, the mailing list is your best resource and SQLAlchemy itself
has quite good documentation.
If you use prototype instead of MochiKit... I have no idea what
happens
You get Prototype instead of MochiKit.
and using another webserver than CherryPy isn't possible right
now, I guess?
Not that I'm aware of. Nor do I think it would make much sense since
CherryPy is the heart of TurboGears. I typically use CherryPy to serve
the dynamic content and a real webserver (Nginx) to serve static files.
I've never felt this was a handicap.
In fact, if you decide to replace so many modules that TurboGears
depend on, what do you gain in using TurboGears at all?
If you got to the point where you were replacing more parts than you
were using, then you'd certainly want to find a different framework as
TurboGears is clearly not for you. I fail to see your point.
Personally I've chosen to go a different route on a couple things and
leave the rest intact. I expect most people are the same. With most
frameworks, there's typically one or two things most people don't like
and it's nice to be able to replace those things without a lot of fuss.
I don't see how that's a liability.
It seems like
the TurboGears developers have a lot of work to do, (and a lot of
documentation to write) if they want to make their framework as easy
to use as others (ie: Django) that takes a more holistic approach.
That's odd, because I've actually used both and found TurboGears far
easier to get started with (no mucking about with Apache and mod_python
for one thing, no need to setup explicit url regexes just to get "hello,
world" on a page).
Judging from your above comments it sounds to me like you're mostly
speculating about TurboGears.
TurboGears more seem to be like emacs than Ubuntu - infinitely
customizable...
Not quite enough IMO, but close enough.
In the future both Rails and TurboGears will probably be great. But
since someone mentioned Rails moving to YARV, and TurboGears moving to
SQLAlchemy and Markup, it seems to me that they are both in a state of
flux and not quite ready yet.
TurboGears is certainly in a state of flux although from an outside
(i.e. API) standpoint it's not nearly as bad as you might think from the
changes that have gone on under the hood. There's been only a few
breaking changes up til now (I converted a site I'd built on 0.8 to the
latest SVN last night and most of the issues I encountered were with my
own changes to TurboStan).
Regards,
Cliff
--
On Thu, 2006-08-31 at 09:04 -0700, Paul Boddie wrote:
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)
And ironically, the one with the *lowest* version number (web.py) is
used to power some fairly large (and ambitious) public projects: https://www.youos.com/ ( see http://blog.youos.com/?p=49 ) http://reddit.com/
I'd like to claim that in OSS, version numbers mean little, but I still
recall Windows NT 1.0 (er, I mean 3.1), so I guess they don't mean much
anywhere. Version numbers are *picked* by project leads for varying
reasons, so comparing version numbers from different projects is pretty
pointless. Is Windows 2000 more stable than Linux 2.6? It ought to be
since it's 769 times more mature, right? Even if you called it Windows
NT 5.0, I'd have to wonder if it's even twice as stable (I'm being
intentionally generous here, so bear with me).
Personally I tend to look at what the users (especially former users)
say about a project and what's been or being done with that project. If
it seems promising, I try it. I can't think of any other reasonable way
of making that decision.
Regards,
Cliff
--
Someone ones said on the mailing list TG is the Ubuntu of web
frameworks, and I think I'll add and you can strip down the kernel and
it wont break :)
But that is not really true. If you use Cheetah instead of Kid, you
lose out: No widgets,
Untrue. Even though I don't use widgets much myself, I wanted to make
sure they *could* be used with TurboStan, so I did a quick test with
Kevin's autocomplete widget. Worked fine. I can't see why Cheetah
would be any different.
Maybe I stand corrected then. But the definition of the
AutoCompleteField widget is here: http://trac.turbogears.org/turbogear...widgets.py#L88
I really don't understand how a completely different non-xml based
templating engine, with a completely different syntax, would be able
to grok that.
If you use SQLAlchemy instead of SQLObject, no identity framework,
Completely false.
Yes, I'm sorry. Last time I used it, it didn't work. But now it seem
to have 100% compatibility.
no administrative tools (tg-admin sql,
True.
CatWalk etc
True.
) and no documentation.
Partially true. The documentation exists but some of it is out-of-date
and it was never very complete to begin with. Of course, like many OSS
projects, the mailing list is your best resource and SQLAlchemy itself
has quite good documentation.
SQLAlchemy does, yes.
If you use prototype instead of MochiKit... I have no idea what
happens
You get Prototype instead of MochiKit.
.... And the docs showing you how to integrate TurboGears with AJAXy
stuff ofcourse no longer applies.
Personally I've chosen to go a different route on a couple things and
leave the rest intact. I expect most people are the same. With most
frameworks, there's typically one or two things most people don't like
and it's nice to be able to replace those things without a lot of fuss.
I don't see how that's a liability.
I disagree, most frameworks do not let you replace its components.
They are a "take it or leave it" kind of deal. I like that. The more
adaptable you try to make a piece of code, the more complex it
becomes. Obviously, it is easier to make code that supports one
templating engine than to make it that supports everyone.
You then most solve that additional complexity. Both in the code AND
in the documentation and you must ensure that the additional
complexity doesn't "leak" and make users life miserable.
I think Jorge claimed that TurboGears was very pluggable and I claimed
that it wasn't so. My point is that making the code pluggable is not
enough. All the stuff around it also need to support the pluggability,
not the least the docs.
That's odd, because I've actually used both and found TurboGears far
easier to get started with (no mucking about with Apache and mod_python
for one thing, no need to setup explicit url regexes just to get "hello,
world" on a page).
Judging from your above comments it sounds to me like you're mostly
speculating about TurboGears.
Not so. During 3 months a few months ago I've built a pretty big web
application using TurboGears. The easy of use of a framework isn't
writing "hello, world" applications, it is finding out how to do
things, doing them and how fast you can do it.
In the future both Rails and TurboGears will probably be great. But
since someone mentioned Rails moving to YARV, and TurboGears moving to
SQLAlchemy and Markup, it seems to me that they are both in a state of
flux and not quite ready yet.
TurboGears is certainly in a state of flux although from an outside
(i.e. API) standpoint it's not nearly as bad as you might think from the
changes that have gone on under the hood. There's been only a few
breaking changes up til now (I converted a site I'd built on 0.8 to the
latest SVN last night and most of the issues I encountered were with my
own changes to TurboStan).
You must have been luckier than me then or maybe you didn't use much
advanced functionality? I converted a site from SVN head somewhere at
0.9 to 1.1 and there were lots of breakages. Anyway, I think we have
different definitions for "not quite ready." Lets say you have to
build and maintain a site or web application together with two other
developers who (like most web developers) doesn't know Python. Would
you then choose TurboGears?
--
mvh Björn
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?
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...
On 8/31/06, BJörn Lindqvist <bj*****@gmail.comwrote:
On 8/31/06, Jorge Vargas <jo**********@gmail.comwrote:
On 31 Aug 2006 08:24:29 -0700, Adam Jones <aj*****@gmail.comwrote:
I believe that is the most important part of TG, taking the best of
the best, and letting the framework adapt and morphe.
for example noone plan to move to SA, 0.1 came out a couple of people
took and look and like it, then 0.2 was "mature enough" so people
started thinking about the migration. after that some code was made
and now we have TG with SA, eventually it will be the default.
Same with templates, kid is really weak at generating non-xml, it has
a plain text serializer but the input must be xml so that's overkill.
So a new template frontend (chettah was born).
Someone ones said on the mailing list TG is the Ubuntu of web
frameworks, and I think I'll add and you can strip down the kernel and
it wont break :)
But that is not really true. If you use Cheetah instead of Kid, you
lose out: No widgets,
that is not correct all widgets have a template attribute which yes
it's kid but replacing it is as simple as changing it's value to a
Cheetah template.
no auto-generated code and the (incomplete)
that is not correct, the only part I can think about is not having
default templates, which are just a demostration/sample app. other
then master.kid I don't think any of the others are used, and the
concept of master.kid doesn't exists in cheetah I think,
if you are really concern about this please create pasteScript with
the chettah default templates and I'll make sure it gets into the
trunk as the sqlalchemy autogenerated code did.
documentation won't apply anymore (it assumes Kid templates ofcourse).
actually no, you get a dict of values into your template, now if your
talking about teaching how to use the "other templating engines" then
I suggest you read their docs, because at that point TG changes
nothing (except 2 or 3 variables that are populated by TG into the
templates)
If you use SQLAlchemy instead of SQLObject, no identity framework,
not true it was commited together with the support for SA 0.2
no administrative tools (tg-admin sql, CatWalk etc)
ok first tg-admin sql is just a wrapper around sqlobject-admin so the
lack of that tool is actually a lack in SA.
about Catwalk and model designer they where created to work with SO,
in fact they are so couple that probably a new tool will be written.
and no documentation.
yes we had many troubles with that we have went from one system to
another but we settle with rest and are going to use moinmoin for a
while until docudo is ready. all the docs are being integrated there
and as we have said there wont be 1.0 until we have lots of docs.
If you use prototype instead of MochiKit... I have no idea what
happens
MochiKit is the most decouple part of the project you can include
almost anything as long as the javascript doesn't collide with
eachother (for example there was a problem with prototype and MochiKit
used together a couple of months ago)
and using another webserver than CherryPy isn't possible right
now, I guess?
there have been some initiatives (experiments mostly about it, and
docs about it on trac) and they work although changing CP is the most
challenging part and I don't think anyone involve with the project
wants that, although you are welcome to try, if X becomes a
replacement for CP we'll migrate to it. all that needs to be done is
write the method/paths logic and make X handle dictionaries as return
values.
you may as well make your own smash up of tools if you want to replace
all components
a couple of emails below you said you just wanted to say that there is
no infix replace and I never said it was like that I said if you want
to change it go ahead the framework wont stop you like happens with
RoR or Django.
at last I dont' agree with you that making the framework support more
things makes it more complex, TG design is genious in that part for
example all template plugins (which are small package define a small
set of variables (actually a class, or abstract class or interface,
whatever you want to call it.) http://www.turbogears.org/docs/plugins/template.html so after that the
rest of the code doesn't cares about which render is actually going to
be use.
and that's why the same TG app can render with more then one
templating engine at the time. in fact you can have the same method
render with 2 different engines if you may need it.
In fact, if you decide to replace so many modules that TurboGears
depend on, what do you gain in using TurboGears at all? It seems like
the TurboGears developers have a lot of work to do, (and a lot of
documentation to write) if they want to make their framework as easy
to use as others (ie: Django) that takes a more holistic approach.
TurboGears more seem to be like emacs than Ubuntu - infinitely
customizable...
In the future both Rails and TurboGears will probably be great. But
since someone mentioned Rails moving to YARV, and TurboGears moving to
SQLAlchemy and Markup, it seems to me that they are both in a state of
flux and not quite ready yet.
--
mvh Björn
--
http://mail.python.org/mailman/listinfo/python-list
fuzzylollipop wrote:
Paul Boddie wrote:
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.
Please note the distinction between "stable" and "mature" - these are
not quite the same thing. Django, Rails and Turbogears may be at or
approaching 1.0, meaning that their developers regard them as being
stable (ie. no showstopping bugs), but that's not the same as being
mature. Moreover, the developers of all those frameworks will most
likely not stop at 1.0 but start working towards 2.0, possibly creating
quite a different product.
I never ever mentioned comparing version numbers between differing packages.
No, but there are important psychological factors at work when choosing
and interpreting version numbers: do you go for ABC 0.9, XYZ 1.2 or PQR
7.1? What about the newly announced XYZ 2.0 - is that a safer choice
than its 1.x predecessor?
MY POINT was the developers of Rails JUST RECENTLY decided that it was
ready for general consumption compared to all the PREVIOUS Rails
releases.
That judgement call may be true, but they haven't exactly been reticent
about getting people to download and use it before now.
And NONE of these frameworks has been used to power anything along the
scale of what I work with on a daily basis.
I can believe that. Do you have any success stories to share?
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 feeling was that any object-relational mapper that (supposedly in
this case) dictates how you're supposed to design your database
automatically rules itself out over a vast territory of existing and
new applications. Having seen the EJB army march themselves into a
swamp, my feeling is that most such mappers seem to be an increasingly
complicated excuse not to learn SQL.
Paul ke****************@sbcglobal.net wrote:
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
I've found that familiarity with Windows in the Ruby/Rails community is
less than in the Python/TG community. Ruby/Rails seems to have been
mainly *nix until fairly recently.
Sometimes the Windows version of a module or tutorial will lag
significantly. (ldap comes to mind.) Sometimes Windows-oriented
questions get pretty short shrift along the lines of: "Perish the
thought!" or "Why would you?" instead of serious treatment.
It's not a deal-breaker and neither community is perfect in this
respect. I now work mostly with Ruby/Rails, but I did Python/CherryPy
for quite a while, and that's my impression.
Ron This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Fred |
last post by:
Not much expertise on XSLT and trying to understand it's uses when creating
apps in VS.NET?
If I wanted flexibility on the UI (View aspect of M.V.C.):
- How does it compare with creating...
|
by: scott |
last post by:
Hi,
Just wondering what sort of problems and advantages people have found using
stored procedures. I have an app developed in VB6 & VB.NET and our
developers are starting to re-write some of the...
|
by: Aspersieman |
last post by:
On Wed, 05 Nov 2008 08:35:23 +0200, 3000 billg <billg3000@hos.twgg.org>
wrote:
Hi
Excellent choice :)
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
