I'm going the opposite direction: after having done two non-trivial RoR apps I have a Pylons project on my hands right now. What can I say? Pylons is a baby Rails and Python is a baby Ruby. Language issues aside, Pylons' architecture seem to be a little cleaner than Rails, but even that advantage largely goes away with all these cleanups done in Rails 2.0.
Pylons/Python are more ugly and less complete than Rails/Ruby:
a) Ugliness: passing "self" to each method, deriving from Object all the time and having __foo__() method names is ugly, ugly, ugly.
b) Incompleteness: URL generation/routing and SQLAlchemy are too primitive and require more coding comparing to Rails. Stuff like form_for(Model.new) isn't possible as far as I can tell. Moreover, Pylons application requires a lot of bootstrapping to get going, setting up DB access is especially tedious comparing to ActiveRecrod's magic. Ralis' soft inforcement and helpers' assistance with RESTful controllers can't be seen anywhere in Pylons as far as I can tell. The list goes on: Pylons is more like a very very old Rails version distorted by ugly Python's object system.
Pylons probably looks pretty sweet to someone who's starting on it with a fresh head, but after two years on Rails I am less than thrilled to work with it. I may not be Pylons expert by now, but man... it's been two months and it still doesn't show me any love :-)
I love Python though. I like CPython implementation and quality of the libraries. Right now it's my language of choice for any stand-alone piece of software, but I try as hard as I can to avoid Python's object system.
b) form_for(Model.new) is great. That's why I've successfully gotten it added in the next version of Pylons. SQLAlchemy is a zillion times more powerful than ActiveRecord, but if you need hand-holding, you can use an AR-ish layer on top of it, such as Elixir: http://elixir.ematia.de/trac/wiki
I've been using Rails for a year and a half, and every time I get a chance to work in Pylons, it's like a breath of fresh air.
It seems to me that the Python fans in this argument are conflating two separate concerns here:
1) Requiring self for access to member variables and methods is a great idea, and is why Hungarian notation like m_foo for a member called foo is popular in languages that don't require it. Ruby does this with @, which is also nice because it's short; I know people who use m_foo in C++ because it's shorter than this.foo, and while I don't agree with them, I can kind of see how a shorter prefix would be nice. But Ruby does lose points in my book for not requiring self/@ for access to object-local methods.
2) Requiring self as an explicit parameter in method definitions confuses the living crap out of newbies. I've seen this several times in the real world. Try explaining it to someone who doesn't yet understand OOP sometime, it's a disaster. On the other hand, making self a magic keyword that gets you the present object, the way Java and C++ handle this, is less confusing, less typing, and has a perfectly nice symmetry between the scope of the definition (method foo is declared on objects of class Bar) and the namespace visible in the call (bar.foo() calls a method foo on the bar object). In contrast, self looks like an explicit parameter in the definition, but doesn't look that way in the call. If you want def foo(self), I think the consistent thing is to do like CLOS and call it like foo(bar) rather than bar.foo(). If you want bar.foo(), something like def self.foo() would be less confusing.
Reason 1: Because they make code easier to read. Purely subjective. I strongly disagree; Ruby is more concise, and ivar access is clearly seperate from method calls.
Reason 2: Because Python will allow you to "cast" self to a superclass to grant explicit access to its variables. Ruby doesn't have this problem.
Reason 3: Because Python would rather overload the keyword "self" than allocate a sigil (@).
The beauty of Python, is that there is a lot of choices when it comes to frameworks. Actually, probably Python is one of the those langues which makes using a framework strictly optional. And there are so many options if you do things that are not your average web app.
With Ruby, you are stuck with one, good framework, but not much if you want to do things very differently.
Django, Pylons, Cherry.py, web.py, Turbogears, and countless of other frameworks.
And I completely agree, on the fact that object oriented programming in Python is not pretty at all, but as a language it wasn't necessary ment to be used that way.
Before picking Pylons I looked at Cherry.py very closely and I actually liked it the most. The reason why we decided to go with Pylons was that it seemed as Cherry.py is being abandoned by everybody in favor of Paste.
But as a lightweight way of exposing Python code to the web I found it very elegant.
Comments
I'm going the opposite direction: after having done two non-trivial RoR apps I have a Pylons project on my hands right now. What can I say? Pylons is a baby Rails and Python is a baby Ruby. Language issues aside, Pylons' architecture seem to be a little cleaner than Rails, but even that advantage largely goes away with all these cleanups done in Rails 2.0.
Pylons/Python are more ugly and less complete than Rails/Ruby:
a) Ugliness: passing "self" to each method, deriving from Object all the time and having __foo__() method names is ugly, ugly, ugly.
b) Incompleteness: URL generation/routing and SQLAlchemy are too primitive and require more coding comparing to Rails. Stuff like form_for(Model.new) isn't possible as far as I can tell. Moreover, Pylons application requires a lot of bootstrapping to get going, setting up DB access is especially tedious comparing to ActiveRecrod's magic. Ralis' soft inforcement and helpers' assistance with RESTful controllers can't be seen anywhere in Pylons as far as I can tell. The list goes on: Pylons is more like a very very old Rails version distorted by ugly Python's object system.
Pylons probably looks pretty sweet to someone who's starting on it with a fresh head, but after two years on Rails I am less than thrilled to work with it. I may not be Pylons expert by now, but man... it's been two months and it still doesn't show me any love :-)
I love Python though. I like CPython implementation and quality of the libraries. Right now it's my language of choice for any stand-alone piece of software, but I try as hard as I can to avoid Python's object system.
a) There are excellent reasons why Python requires passing 'self' to each method. The article linked to three of them; I'll just link to one: http://effbot.org/pyfaq/why-must-self-be-used-explicitly-in-...
b) form_for(Model.new) is great. That's why I've successfully gotten it added in the next version of Pylons. SQLAlchemy is a zillion times more powerful than ActiveRecord, but if you need hand-holding, you can use an AR-ish layer on top of it, such as Elixir: http://elixir.ematia.de/trac/wiki
I've been using Rails for a year and a half, and every time I get a chance to work in Pylons, it's like a breath of fresh air.
It seems to me that the Python fans in this argument are conflating two separate concerns here:
1) Requiring self for access to member variables and methods is a great idea, and is why Hungarian notation like m_foo for a member called foo is popular in languages that don't require it. Ruby does this with @, which is also nice because it's short; I know people who use m_foo in C++ because it's shorter than this.foo, and while I don't agree with them, I can kind of see how a shorter prefix would be nice. But Ruby does lose points in my book for not requiring self/@ for access to object-local methods.
2) Requiring self as an explicit parameter in method definitions confuses the living crap out of newbies. I've seen this several times in the real world. Try explaining it to someone who doesn't yet understand OOP sometime, it's a disaster. On the other hand, making self a magic keyword that gets you the present object, the way Java and C++ handle this, is less confusing, less typing, and has a perfectly nice symmetry between the scope of the definition (method foo is declared on objects of class Bar) and the namespace visible in the call (bar.foo() calls a method foo on the bar object). In contrast, self looks like an explicit parameter in the definition, but doesn't look that way in the call. If you want def foo(self), I think the consistent thing is to do like CLOS and call it like foo(bar) rather than bar.foo(). If you want bar.foo(), something like def self.foo() would be less confusing.
Reason 1: Because they make code easier to read. Purely subjective. I strongly disagree; Ruby is more concise, and ivar access is clearly seperate from method calls.
Reason 2: Because Python will allow you to "cast" self to a superclass to grant explicit access to its variables. Ruby doesn't have this problem.
Reason 3: Because Python would rather overload the keyword "self" than allocate a sigil (@).
The beauty of Python, is that there is a lot of choices when it comes to frameworks. Actually, probably Python is one of the those langues which makes using a framework strictly optional. And there are so many options if you do things that are not your average web app. With Ruby, you are stuck with one, good framework, but not much if you want to do things very differently.
Django, Pylons, Cherry.py, web.py, Turbogears, and countless of other frameworks.
And I completely agree, on the fact that object oriented programming in Python is not pretty at all, but as a language it wasn't necessary ment to be used that way.
In Ruby you've also got a bunch of Web frameworks/libraries (Rails, Merb, Camping, Rack, Ramaze, Sinatra, and Nitro, to name a few).
You are really not stuck with Rails if you're using Ruby. This isn't a fair critique.
Before picking Pylons I looked at Cherry.py very closely and I actually liked it the most. The reason why we decided to go with Pylons was that it seemed as Cherry.py is being abandoned by everybody in favor of Paste.
But as a lightweight way of exposing Python code to the web I found it very elegant.