views:

6200

answers:

15

Python and Ruby are usually considered to be close cousins (though with quite different historical baggage) with similar expressiveness and power. But some have argued that the immense success of the Rails framework really has a great deal to do with the language it is built on: Ruby itself. So why would Ruby be more suitable for such a framework than Python?

+1  A: 

Some have said that the type of metaprogramming required to make ActiveRecord (a key component of rails) possible is easier and more natural to do in ruby than in python - I do not know python yet;), so i cannot personally confirm this statement.

I have used rails briefly, and its use of catchalls/interceptors and dynamic evaluation/code injection does allow you to operate at a much higher level of abstraction than some of the other frameworks (before its time). I have little to no experience with Python's framework - but i've heard it's equally capable - and that the python community does a great job supporting and fostering pythonic endeavors.

Faisal Vali
Indeed, this sort of "magic" is often frowned upon in Python; for example, http://code.djangoproject.com/wiki/RemovingTheMagic
ephemient
I think "magic" (metaprogramming tricks) for the sake of "magic" should always be frowned upon - simpler code, but equally powerful and expressive, should always win - but there are cases when the only way to provide the *exact* functionality and syntax you want requires "magic" - and in those cases, the "magic" is indispendable ;)
Faisal Vali
+36  A: 

Those who have argued that

the immense success of the Rails framework really has a great deal to do with the language it is built on

are (IMO) mistaken. That success probably owes more to clever and sustained marketing than to any technical prowess. Django arguably does a better job in many areas (e.g. the built-in kick-ass admin) without the need for any features of Ruby. I'm not dissing Ruby at all, just standing up for Python!

Vinay Sajip
"E.g. the built-in kick-ass admin"? More like "only the built-in admin". That's a great feature, but I can't really think of anything else of note to recommend it over Rails unless you just like Python.
Chuck
Well, we're getting into subjective territory here. If you think the admin is an "only", then perhaps it's because you have not enjoyed the time-saving benefits it confers. Are there any areas that you think Django does worse than Rails, because of features which Ruby has and Python doesn't? The point really isn't about which framework is better - it's whether (as pointed out elsewhere in this question) there's anything lacking in Python which makes it less capable of developing a kick-ass framework. On the evidence, there's no such lack.
Vinay Sajip
Marketing as in "everyone who uses it loves to talk about how much they like it"? I would say Django has at least as good marketing as rails, it just hasn't been around for as long.
Matt Briggs
I agree the admin interface is a great feature. It's not an "only" because it's unimpressive; it's an "only" because it's the only one.
Chuck
@Matt Briggs: I agree that Django's marketing is pretty good, but no way is it as in-your-face as DHH ;-) @Chuck: I agree it's more subjective in the other areas. See my earlier meta-point about what my actual point was ;-)
Vinay Sajip
@To the downvoters: I don't really mind, but I'm curious to know why you thought that my answer was *unhelpful*. I didn't realise one downvoted because one disagreed with someone's position - I generally have downvoted only where I felt that a question or answer was somehow making things worse.
Vinay Sajip
I can write my own admin section, I don't need this is in framework. I prefer other ways of making my application easier to write.
railsninja
@railsninja: Good for you. I prefer not to have to write boilerplate pages for admin housekeeping chores that most systems need. Recently, I did some pro-bono work for a local charity website, and it wouldn't have been feasible to do that site at all if the Django admin were not part of the equation. As it was, I provided a site with a fairly customised Ajaxified UI for the end users, but back end administrators worked with the admin and it was more than adequate for their needs.
Vinay Sajip
@Vinay: You aren't answering his question, you are commenting on it. His question is "What makes ruby suitable for a platform like rails?" not "Why is ruby better then python?" or "What other platforms are better then rails?"
Matt Briggs
@Matt: I thought I did answer his question by addressing (a) what I thought about the possible reasons for Rails' success and (b) that the existence of Django, in being better in at least *some* areas than Rails, demonstrates that Ruby is not necessarily *more* suitable than Python for developing a framework in the same space. Obviously in this context *more* is of necessity a subjective measurement rather than an objective one.
Vinay Sajip
@Matt: His question is why Ruby is MORE suitable than Python.. And the answer, quite correctly, is that it isn't.
Lennart Regebro
@Vinay: Sorry about being pedantic/nitpicky, but a) I would consider that a comment rather then an answer, and b) is completely irrelivent, since the question wasn't about web frameworks in general, but rails in particular. Again, I don't want to jump down your throat or anything, but I think the only reason you got 20 votes is because of people who are pro django/hate rails, not because it is a good answer to this particular question.
Matt Briggs
@Lennart: His question was why is ruby MORE suitable than python FOR RAILS. The answer didn't come close to answering it, it argued against an earlier statement in the question and plugged an alternate framework.
Matt Briggs
@Matt - I read the question carefully. It states "such a framework", which I interpreted as "a framework in the same space/of the same type". And I have to grin ruefully at all the down-votes I've got for this answer - but then I don't make a religion out of picking frameworks, they're just tools to help you do your job.
Vinay Sajip
@Vinay: No point getting into these stupid arguments. The question itself is a flamebait. Don't feed the trolls.
Baishampayan Ghose
More fanbois than trolls, I would say. Anyway, I'm not planning on devoting more time to this unless something interesting turns up :-)
Vinay Sajip
It's not worth fighting over who's language is better. The more people who join the Ruby bandwagon, the better for me (python developer) because as the Python community becomes more enterprise (as it is (look at unladen swallow)) and I'm making 180k in aerospace, Rubinians will still be building hundreds of slight variations of the same CMS and/or blog and/or social networking site... for free.
orokusaki
+112  A: 

There are probably two major differences:

Ruby has elegant, anonymous closures.

Rails uses them to good effect. Here's an example:

class WeblogController < ActionController::Base
  def index
    @posts = Post.find :all
    respond_to do |format|
      format.html
      format.xml { render :xml => @posts.to_xml }
      format.rss { render :action => "feed.rxml" }
    end
  end
end

Anonymous closures/lambdas make it easier to emulate new language features that would take blocks. In Python, closures exist, but they must be named in order to be used. So instead of being able to use closures to emulate new language features, you're forced to be explicit about the fact that you're using a closure.

Ruby has cleaner, easier to use metaprogramming.

This is used extensively in Rails, primarily because of how easy it is to use. To be specific, in Ruby, you can execute arbitrary code in the context of the class. The following snippets are equivalent:

class Foo
  def self.make_hello_method
    class_eval do
      def hello
        puts "HELLO"
      end
    end
  end
end

class Bar < Foo # snippet 1
  make_hello_method
end

class Bar < Foo; end # snippet 2
Bar.make_hello_method

In both cases, you can then do:

Bar.hello

which will print "HELLO". The class_eval method also takes a String, so it's possible to create methods on the fly, as a class is being created, that have differing semantics based on the parameters that are passed in.

It is, in fact, possible to do this sort of metaprogramming in Python (and other langauges, too), but Ruby has a leg up because metaprogramming isn't a special style of programming. It flows from the fact that in Ruby, everything is an object and all lines of code are directly executed. As a result, Classes are themselves objects, class bodies have a self pointing at the Class, and you can call methods on the class as you are creating one.

This is to large degree responsible for the degree of declarativeness possible in Rails, and the ease by which we are able to implement new declarative features that look like keywords or new block language features.

Yehuda Katz
In Python, everything is objects and all lines of code are directly executed too. ;) But, you don't have a "self" pointing at the class in the class body, that doesn't get created until after the class definition, so you have to put that code afterwards in Python, which admittedly is less elegant, but functionally equivalent.
Lennart Regebro
ruby makes my head ache in (awesomenss|static pain)
Manuel Ferreria
@lennart that's kind of the point. Python allows you to do the same kinds of things with named lambdas, decorators, and putting code after classes are created, but the loss in elegance adds up quickly and makes something like Rails either noticeably harder to implement or noticeably less elegant for end users.
Yehuda Katz
They don't really look like major differences to me.
Dietrich Epp
@Yehuda You don't need any of these things to make a web framework like Rails. At least not in Python. And I don't see what you have against decorators. :-)
Lennart Regebro
@lennart I'm a bit confused. I said that you didn't need them in Python -- but that not having them made the code harder to implement or less elegant for end users (one or the other). The languages are turing complete--you can write Rails in C if you want.
Yehuda Katz
@Yehuda: No, the code is not hard to implement nor less elegant. I'm not familiar with Rails internals, but I know that in Python there is no need for any of this to make elegant clean code that is also elegant clean and easy for the user. I honestly doubt that it's necessary in Rails either.
Lennart Regebro
@lennart Now we're getting into subjective territory, but the two features I talked about are quite convenient when producing frameworks with a mix of declarative and procedural programming. The lack of anonymous lambdas, in particular, is an expressiveness limitation of Python. The lack of consistency (the need to work with created classes only AFTER classes were created) is quite limiting as well.
Yehuda Katz
For a good example of this, take a look at Merb/Rails' router vs. Django's router. At MerbCamp last year, we had a talk on "things the Merb community can learn from Django." Of course, the admin and the concept of "apps" featured prominently. But he also enthusiastically preferred the Merb-style router to Django's, which would be significantly less expressive without the use of anonymous lambdas.
Yehuda Katz
Firstly, you seem to claim that anonynmous lambdas are missing in Python. That's a strange claim. Lambdas are anonymous functions. If it wasn't anonymous, it would simply be a function.Secondly, you *never* need to use anonymous lambdas in Python. Or lambdas at all. Any use of Lambdas in python can be replaced with a function. If this is not the case in Ruby, then that's a weird limitation in Ruby, not in Python.
Lennart Regebro
If you need to work with the classes during construction in Python, you use metaclasses or class decorators. I agree metaclasses can be hairy, and class decorators are new (but not very hairy). But you claim you *need* to do this to make a good webframework, yet neitehr you, nor anybody else has provided any argumentation on why a webframework using these things would be better.My conclusion from the lack of argumentation is that this is nonsense.
Lennart Regebro
@lennart I think you need to take a look at Lisp, Smalltalk, JavaScript or Ruby again, all of which make heavy use of anonymous functions (also known formally as lambdas). Because the functions can be defined anonymously, they can be used as syntax elements, rather than as procedural constructs. This makes creating your own language-looking constructs much easier. It is also the reason for Ruby's lightweight block construct.
Yehuda Katz
@lennart check out this implementation of Python decorators in Ruby: http://gist.github.com/144883. I'm waiting for your 22 loc implementation of Ruby metaprogramming in Python.
Yehuda Katz
@Yehuda: You seem to continue claiming that Python doesn't have lambdas. You simply make no sense.I keep waiting for arguments that the metaprogramming in Ruby is necessary for web frameworks. This is not a question of what is better in Ruby vs Python in general. It's a question of why Ruby would be better for rails-type frameworks. No such argumentation has come forward.You don't seem to either understand that distinction, nor know what you are talking about when it comes to Python.
Lennart Regebro
@Lennart: Web frameworks are more elegant when they are written in Ruby. How's that?
musicfreak
Well, they aren't, quite simply. I've now spent hours and hours investigating the claimes that anonymous closures would create more elegance, and sorry, it's just wrong. There is nothing to substantiate that claim. Thanks to all that helped.http://stackoverflow.com/questions/1113611/what-does-ruby-have-that-python-doesnt-and-vice-versa/
Lennart Regebro
@lennart at this point you're just repeating your subjective opinion over and over and over again. This post has already been closed for subjective and it would probably be helpful at this point if you just let your subjective comments stand on their own and stopped repeating them.
Yehuda Katz
Why is this a good example of how blocks are used in ruby? Why can't this be a case statement? http://gist.github.com/155906
pjb3
I like the fact that you don't have to ever use "=>", ":", "@", or "<" in regular syntax. Those are special characters that in a well-designed language only serve special purposes, like delimiting a dictionary's key-value pairs, or using a decorator, or (in reverse) meaning greater than or equal to, or less than.Let me put it simple: Without programming experience, you could not look at Ruby and begin to understand anything.
orokusaki
@pjb3 Because w/ format, you get a chance to do default actions (like format.html that doesn't take a block) and you get an error if you expect a format you don't have configured (like format.foo when you haven't configured a MIME type for "foo"). It's using Ruby's blocks to implement a lot more logic than just a straightforward conditional logic.
BRH
Django code is much easier to read than what's shown here.
FogleBird
+8  A: 

Python has a whole host of Rails-like frameworks. There are so many that a joke goes that during the typical talk at PyCon at least one web framework will see the light.

The argument that Rubys meta programming would make it better suited is IMO incorrect. You don't need metaprogramming for frameworks like this.

So I think we can conclude that Ruby are not better (and likely neither worse) than Python in this respect.

Lennart Regebro
A: 

All of this is TOTALLY "IMHO"

In Ruby there is ONE web-application framework, so it is the only framework that is advertised for that language.

Python has had several since inception, just to name a few: Zope, Twisted, Django, TurboGears (it itself a mix of other framework components), Pylons (a kinda-clone of the Rails framework), and so on. None of them are python-community-wide supported as "THE one to use" so all the "groundswell" is spread over several projects.

Rails has the community size solely, or at least in the vast majority, because of Rails.

Both Python and Ruby are perfectly capable of doing the job as a web applications framework. Use the one YOU (and your potential development team) like and can align on.

Ch'marr
ruby has multiple web application frameworks: Nitro, Merb, Camping.. to name a few
Corban Brook
Add: Sinatra and even a bare Rack app for very fast very minimal web apps as well.
Kris
-1 "In Ruby there is ONE web-application framework" too categorical... for a false statement. Nitro, Merb, Camping, Sinatra
Maximiliano Guzman
Uninformed opinions from either side are exactly the cause of confusion for newcomers who are trying to sort all this out. It also means one could be missing out on something they would actually appreciate if they knew better.
Walt Gordon Jones
I think his point was that Rails has a large mindshare of the Ruby community than Django has of the Python community, which is valid
pjb3
Why was this voted down? Rails themselves speak of them being the only framework for Ruby. Sure, there are others but that's not the mentality of rails users. In fact, there was a popular one that came out a couple years back that was more basic and simple and Rails merged them in with themselves (don't remember the name).
orokusaki
+31  A: 

The python community believes that doing things the most simple and straight forward way possible is the highest form of elegance. The ruby community believes doing things in clever ways that allow for cool code is the highest form of elegance.

Rails is all about if you follow certain conventions, loads of other things magically happen for you. That jives really well with the ruby way of looking at the world, but doesn't really follow the python way.

Matt Briggs
Sure, but there are loss of Perl people (well, maybe not *lots*) who think that cryptic one-liners are cool, and many Lisp people who swear that it's the one true language. We're definitely in whatever-floats-your-boat territory.
Vinay Sajip
Yeah, I wasn't making value judgements or anything. Personally, I find the ruby way more fun, but I think the python way is the better way to develop larger projects, especially in a team or distributed setting.
Matt Briggs
Rails has zero magic, it is right there in the source. If you want to know how, get off your ass and find out.
railsninja
"Any sufficiently advanced technology is indistinguishable from magic." - Arthur C. Clarke
Vinay Sajip
"magic" meaning the framework does a heck of a lot of things for you without being directly asked. Again, I am not making value judgments, it is one style of doing things that has good sides and bad sides. Personally, I think it works wonderfully in rails.
Matt Briggs
"The ruby community believes doing things in clever ways that allow for cool code is the highest form of elegance." — This is a generalization, I think every language has it's portion of "geniuses."
heycarsten
Elegance and conventions do not denote magic.
BJ Clark
@BJ: Based on your profile, you are a ruby guy, in which case you prove what i am saying. Rails does not do things in what people call a "pythonic" way.
Matt Briggs
"It's still magic even if you know how it's done." -- Terry Pratchett
David Moles
It's not "clever ways" and "cool code" that are valuable, it's "efficient ways" and "succinct code".
alpav
it depends on what you consider clever and cool I guess.
Matt Briggs
I think this answer summarizes all the matter. It is clear that there is no absolute BEST language/framework. You should work whatever philosophy you like more and thanks God there's a lot of options available. Questions like these are productive when you aim to exchange approaches and knowledge and not to make non-sense comparisons. Just FYI: I'm on the Ruby side. =)
Lailson Bandeira
I've always thought of the ruby philosophy as "arrange things so the easiest way to do something is also the best way". In other languages, I've found that in order to "fully take advantage of the language constructs", I need to obfuscate my code in such a way that it's harder to read and doesn't really express what I meant. In ruby, I rarely have to do that to produce efficient code.
fields
+13  A: 

Personally, I find ruby to be superior to python in many ways that comprise what I'd call 'consistent expressiveness'. For example, in ruby, join is a method on the array object which outputs a string, so you get something like this:

» numlist = [1,2,3,4]
=> [1, 2, 3, 4]
» numlist.join(',')
=> "1,2,3,4"

In python, join is a method on the string object but which throws an error if you pass it something other than a string as the thing to join, so the same construct is something like:

» numlist = [1,2,3,4]
» numlist
[1, 2, 3, 4]
» ",".join([str(i) for i in numlist])
'1,2,3,4'

There are a lot of these little kinds of differences that add up over time.

Also, I cannot think of a better way to introduce invisible logic errors than to make whitespace significant.

fields
My experience is that making whitespace significant helps logic errors go away. It's much more confusing to have spacing and syntax disagree.
Nosredna
So what do you do when someone copies a block of code and the whitespace gets mangled? How do you tell what indent level each part of the block is supposed to have?
fields
Or, more to the point, how do you even tell that something is wrong until it breaks in a way you didn't expect (and which may not be evident until much later)?
fields
In languages with begins and ends and in languages with braces and in assembly, I've seen code get pasted in wrong and cause trouble later. That's always a problem. Have you had a lot of trouble with people pasting Python badly?
Nosredna
I have - I've spent literally hours fixing other people's code that's been mangled this way without their noticing. Skype is also particularly bad - it collapses leading whitespace and there's no way to turn that off that I can find. At least if you're missing a brace or an end it will throw a syntax error or your text editor will warn you, but there's no way for the machine to know when you've got your indenting wrong but it's still valid.
fields
For me the fact that I need to put in lot's of space wasting "ends" in Ruby more than makes up for lack of obscure "nice" features.
Kozyarchuk
Whitespace is not significant in Python: http://www.secnetix.de/~olli/Python/block_indentation.hawk . It's almost impossible to introduce "invisible errors" due to indentation in Python (you have to fudge your editor settings) while of course it is completely possible to introduce invisible errors due to indentation in any other language, simply by indenting incorrectly.@fields: So don't copy code via skype or HTML, then. Geez.
Lennart Regebro
It is correct that Python complains if you try to add non-strings to strings, like in a Join. This is because explicit is better than implicit. There are very few automatic conversions in Python, and the reason for that is that they tend to lead to problems, especially in dynamic languages, since things end up not being the type you expected it to be.Sure the "".join() method does feel backwards in the beginning, but that's the reason. It actually doesn't make sense on the list...
Lennart Regebro
@Lennart: "explicit is better than implicit" does not make any sense in the context of a weakly typed language. If you want strong types, then more power to you (and neither python nor ruby is really for you), but a lot of value in a weakly typed language lies in having the interpreter do implicit conversions for you where it makes sense to do so. The return value of join is a string, so why not convert everything to a string?"So don't copy code via skype or HTML, then." - or I'll just work in a language that won't be destroyed by my most common ways of collaboration with distributed teams.
fields
Yeah, except that Python is strongly typed.
Lennart Regebro
Python is definitely not strongly typed because it can't check type collisions at compile time. Without that, I'm left wondering what the real benefit of python's type checking is, especially in the face of ruby's adherence to capability checking instead of strict typing. If you can represent a number as a string, who really cares if it's not strictly a "string" type?
fields
God almighty...You mean statically typed, not strongly typed. Python is strongly typed, So is Ruby:http://stackoverflow.com/questions/520228/is-ruby-strongly-or-weakly-typedYou can't add a string to an integer in Ruby either. I'm getting tired of correcting you, please check your facts before you answer in the future.
Lennart Regebro
Google the phrase 'python is strongly typed'. It's fairly unanimous
andybak
@Lennart "explicit is better than implicit" only with per-line code readability goal, which is Python goal. Ruby goal is succinctness and with that goal implicit is better than explicit.
alpav
@alpav: Do you have reference to that goal? Because I have a hard time believing it, as it would be... well, the nicest word I can come up with is "misguided".
Lennart Regebro
About goals of Python and Ruby: [Python's goal is regularity and readability, not succinctness](http://www.paulgraham.com/power.html), Matz on Ruby:[making programming faster and easier](http://www.scribd.com/doc/15491138/The-Ruby-Programming-Language-by-OReilly-Media)
alpav
+10  A: 

The real answer is neither Python or Ruby are better/worse candidates for a web framework. If you want objectivity you need to do some projects in both and see which fits your person preference best. Most people who argue for one or other have either never used the other language seriously or are 'voting' for their personal preference.

I would guess most people settle on which ever they come in to contact with first because it teaches them something new (MVC, testing, generators etc.) or does something better (plugins, templating etc) - I used to develop with PHP and came in to contact with RubyOnRails. If I had have known about MVC before finding Rails I would more than likely never left PHP behind. But once I started using Ruby I enjoyed the syntax, features etc.

If I had have found Python and one of its MVC frameworks first I would more than likely be praising that language instead!

Kris
I got a "Nice Answer" badge for this answer, I don't know if to be pleased or offended - lol. To to be honest Ruby is way way way better than Python ;)
Kris
+21  A: 

I fail to see how

class Foo
  def self.make_hello_method
    class_eval do
      def hello
        puts "HELLO"
      end
    end
  end
end

is elegant ...

doru
it is more elegant than what you have to write in most languages to get the same functionality..
Maximiliano Guzman
It also helps if you write a bit more code to fill out your classes. Contrived examples of overprogramming don't really prove the point.
fields
Agreed, I like my curly braces
jimiyash
@Maximiliano, it's a simple example so it's nothing special. You can use a similar structure to define multiple similar methods that vary slightly. Allowing you to write and change them all at once.
EmFi
I think it's worth noting that it would be half as many lines if you could eliminate all those `end` lines via python-esque significant whitespace /flamebait =P
Jiaaro
class_eval is redundant, you are already in the context of the class.
Matt Briggs
+1  A: 

I suppose we should not discuss the language features per se but rather the accents the respective communities make on the language features. For example, in Python, re-opening a class is perfectly possible but it is not common; in Ruby, however, re-opening a class is something of the daily practice. this allows for a quick and straightforward customization of the framework to the current requirement and renders Ruby more favorable for Rails-like frameworks than any other dynamic language. Hence my answer: common use of re-opening classes.

Giorgi
A: 

"Bar.hello" doesn't work, should be "Bar.new.hello". Typo?

Zipme
+4  A: 

Because Rails is developed to take advantage of Rubys feature set.

A similarly gormless question would be "Why is Python more suitable for Django than Ruby is?".

Paddy3118
+9  A: 

Is this debate a new "vim versus emacs" debate?

I am a python/django programmer and until now i've never found a problem in that language/framework that would lead me to switch to ruby/rails.

I can imagine that it would be the same if I was experienced with ruby/rails.

Both have similar philosophy and are making very good job in a fast and eleguant way. The better choice is what you already know.

luc
A: 

I think that the syntax is cleaner and Ruby, for me at least, is just a lot more "enjoyable"- as subjective as that is!

James Schorr
A: 

Two answers :

a. Because rails was written for ruby.

b. For the same reason C more suitable for Linux than Ruby

Dhananjay Nene