6 ms·

A Django Developer’s Views on Rails

46 points by foobar2k 17y ago

carbon8 17y ago
"Python vs. Ruby (Perl’s Ugly Sister)...This makes the Ruby syntax look like someone emptied all the symbols from the keyboard into a shotgun and shot them into your face." It's amazing watching the python web development community develop, nurture and encourage so much mindless trolling. It has turned reddit completely septic and now this garbage is on the front page here? Sigh.
- deleted 17y ago
  [deleted]
- tvon 17y ago
  "It's amazing watching the python web development community develop, nurture and encourage so much mindless trolling." Where are you seeing this? There are a fair number of Django and Python posts on HN and this is the first I've read that I can remember any such trolling.
  - carbon8 17y ago
    "on HN" Indeed, but even here it has been increasing. This made it to #2 within a half hour of posting. Even watching this thread you can see people driving through down modding even mdasen's post. Another recently popular blatant nonsensical anti-rails/pro-django troll that comes to mind was the "Magic Sucks, Django Rocks!" submission: http://news.ycombinator.com/item?id=596833 http://news.ycombinator.com/item?id=596833
- foobar2k 17y ago
  The article was meant to address transition points from django to rails not start a flamewar. I was never encouraged by anyone to "troll", this is from my personal experiences. There's no conspiracy theory here.
  - olifante 17y ago
    As a pythonista who likes ruby, I think your "Perl's ugly sister" comments were a shot in the foot and detracted from the rest of your argument, which concentrates on rails and has little to do with Ruby itself.
    - berntb 17y ago
      Frankly, I'm quite used to see this kind of trolling spam about Perl. You could answer by asking after specific problems with "Perl Best Practices" or what can top e.g. Moose, but language wars (+)? I AM able to grow a beard.... This group of scripting languages seems really similar in functionality and usability today (so if I change environment, I'd probably go functional). The large difference seems to be in the cultures around them... (+) I'm all for editor wars, of course! :-)
- immad 17y ago
  Oh come on, it was funny. You need to lighten up a bit. He gives points on both sides. I do only Ruby and I get what he means.
  - petercooper 17y ago
    What does he mean then? I've looked at quite a bit of Python and Ruby source code and Python uses square brackets, periods, mathematical symbols, parentheses, and colons in similar ways. Indeed, a method definition in Ruby uses fewer symbols (no need for the colon on the end, or even the parentheses, although that's against common Ruby style). Python even makes nonsense like using double underscores in method names obligatory. Or how about Python's obligatory parentheses on all method calls? How is Ruby really more "line noise" than Python? Seriously. Sure, Ruby allows you to be more lax than Python and write poor, "line noisy" code, but good Ruby is no more "line noise" than good Python.
    - sri 17y ago
      ruby uses < (less than) for inheritance; also regular expressions start & end with / (slash). you have %W, %w for arrays and %q, %Q for string. things like "class << self ..." looks weird to those new to ruby. also stuff like "a ||= ...". and of course pre-pending '@' for instance variables and '@@' for class variables. also when i use regexps in ruby i then say "/re(g)ex/ =~ 'string' && $1". in python that would be multiple statements: "m = re.match('re(g)ex', 'string'); m.group(1)" in python existing syntax (or more familiar syntax) is used to accomplish all the above.
      - tptacek 17y ago
        I never use %w for arrays and I never use %Q for strings. After years of schlepping through Python's regular expression support --- support not dissimilar from the regex support C++ has --- /regexes/ are a gift from god. Also, your Ruby vs. Python regex examples aren't even equivalent.
      - petercooper 17y ago
        Sigils on variables are a good point. This is an area where I think Python wins out. Dependence on "self" all over the place is irritating at first but ultimately quite comforting - especially when you wonder whether you're going to screw up your attributes when you use the same name for a local variable in your Ruby method ;-) But on inheritance - you have to put the class name in round brackets in Python, no? That's 2 characters to Ruby's 1. Stuff like a ||= shouldn't be considered Ruby-specific noise as Python also has the same idiom as in a += and a -=, just not with ||. || is arguably noise over "or" but it shouldn't seem like cryptic noise with any sort of experience of C, C++, Java, JavaScript, or almost any other mainstream language. Further, that Ruby code of yours does seem more Perlish than Rubyish, but I suspect this is because Ruby style is gradually shifting away from Perl-like styles to more idiomatic approaches. For example, I'd probably choose 'string'[/re(g)ex/, 1] or if I was trying to be "proper" then something like m = string.match(/re(g)ex/); m[1] (or potentially use Regexp#match, but I far prefer String#match). I see those solutions more typically than those you present - and the latter is quite like your Python example - but.. TMTOWTDI and that's Ruby's greatest asset :)
- olifante 17y ago
  What the hell are you talking about? This is ONE article written by ONE person and suddenly it's the Python community's fault for allowing it to exist? Spare me. This victimization technique should added to the list of Logical Fallacies, if it isn't already there.
look_lookatme 17y ago
What does this article say that hasn't been said before? This stuff just isn't interesting anymore.
- fiaz 17y ago
  What this article says to me is: 1) there exists multiple frameworks that are independently excellent 2) some of the best minds in both worlds have nothing better to do other than to take sides in meaningless discussions
  - stcredzero 17y ago
    some of the best minds in both worlds have nothing better to do other than to take sides in meaningless discussions That and some unsubtle flirting with language wars and trolly word choice is exploitable for linkbait and HN karma.
sreque 17y ago
It is fairly easy to avoid symbol soup in ruby. First, don't use global variables. I'm perfectly OK with global variables sticking out and looking ugly. Second, use the English module packaged with Ruby if you find yourself using Perl-like special global variables a lot. I very rarely use them and so never need to use the module. Finally, use accessor methods to work with instance variables instead of accessing them directly. This also makes it easier to add logic to handle your instance variables without having to rewrite or break any code. If you follow these three steps alone, you will have about the same amount of symbol soup as you would in python, which is almost none. (By the way, I am also a fan of both python and ruby and think they are both great languages).
mdasen 17y ago
In the Rails world, the layer which generates the final markup sent to the browser is called the View layer. In a Rails View, you can chuck as much rails code as you like in amongst your markup. Some of the early sites I worked on many years ago were written in PHP, which had the same idea. Um. . . Sure, you can put any logic you want in a Rails template, but people don't. Rails applications tend to have a nice separation of layout and application logic. Django really likes to constrain users here - not even letting them use a full "if" statement. It's really unfair to just say Rails == Unmaintainable PHP. PHP often becomes that way because there is no immediate way of separating the code. Smarty and others can force you, but both Rails and Django put a really obvious place to put your app logic and developers tend to respect that. Part of this is just how much rope do you give a developer and it's fair to say that one shouldn't give developers that much leeway. However, it's wrong to just equate the two. Multiple Apps in a Project Really, neither framework (or any code) is as pluggable into random situations as we programmers would like. The author suggests that you can use models from different applications in Django. That sounds cooler than it is. They're all running off the same database and in the same project. Really, what Rails creates are projects in Django-speak. And the "apps" convention in Django doesn't help you in development. It helps in organization sometimes - especially the admin interface - but it isn't some spectacular thing where you can just reuse random code in a way that you can't with Rails. Well, I take that back, there is one way that is really nice: namespacing. You can have a blog app that has an Entry and Category model without having to name it BlogEntry and BlogCategory because it would conflict with your Category model for, say, a real estate part of your app. And that is helpful in a way that Rails doesn't solve nicely. However, for the most part Rails and Django provide decently equal utility in this area, they just name the things differently. URL Routing Django's routing is really verbose. You have to specify each route you want. Rails has a bunch of shortcuts for common cases (REST as well as :controller/:action/:id). In a way, this is just the explicit vs. implicit thing. Django makes you explicitly state your URLs while Rails will let you state them, but you don't have to should you like the defaults. The Django folk say that it takes very little time to write routes (true) and that one should be thoughtful when making URLs (also true). But sometimes it just feels tedious. Really, it's just a matter of preference. Ruby (Perl’s Ugly Sister) This is kinda low at some points (why I went to it last - I don't like dwelling on such poor arguments). Ruby doesn't actually use that many symbols ala Perl. All variables are done without symbols; I think strings built as "#{var} is cool" are easier to understand than "%(var)s is cool" % {'var': var}. And it isn't like Python doesn't have weird things like "/".join(list). Really, my beef with Ruby would be how easy (and common) it is to add methods to ancestors without really making it clear. As you start adding methods to Object, you can get yourself into a position where Python's explicitness is really nice. However, when you want to get something done, Ruby can be nice in that respect. It's like having a circular saw: really good for both cutting wood and cutting your hand off. Likewise, Python's mixins are put onto attributes of the model - so that you have things like house.photo.url rather than house.photo_url (although Django did create the second for a long time). That makes it very clear what you're adding while if you say "acts_as_nested_set" in Rails, you don't immediately see which methods are being added. Ruby's problems aren't really syntactic, but it can have things that one could define as problems. -- I've put out two sites in Django and one in Rails and at this point I'm developing two projects in Rails. The Django community is really smart and understated and I still read a lot (smart information translates well to anything), but Django just doesn't see the same pace of development that Rails does. Even something simple such as following reverse foreign keys isn't implemented in Django. Yep, if you try Entry.objects.all(select_related="comments") it will just silently fail (how's that for letting errors pass silently that shouldn't!). And it is difficult and Malcom has way more on his plate than any normal person could even conceive of, but. . . it's still missing. And the Rails community has calmed down a bit, the Merb camp seems to be adding nicely to Rails 3, the Rails framework covers so many more edge cases than it used to as well as just seeming more reliable, and deployment has really stepped up with Passenger. Django is a wonderful piece of software with great features and really smart, considerate people using it. It just isn't seeing as great a push toward little simplifications for more edge cases in the way that Rails has been. Frankly, they're so much alike in all the meaningful ways - I think that's why I have such an easy time wrapping my head around both. Eh, I have to get dinner.
petercooper 17y ago
Sorry Pythonistas, but whenever you say that having "only one way" to do something is a good point (and many have said this), you sound like religious nutjobs. There's more than one good and obvious way to do anything worth doing, be it giving birth, building a bridge, adding two numbers together, or developing algorithms in a programming language. I like Python on many levels - particularly the indentation - but the religious-ness of the philosophy and language design is off-putting in so many other ways.
- jjs 17y ago
  > I like Python on many levels - particularly the indentation - but the religious-ness of the philosophy and language design is off-putting in so many other ways. I think you're overgeneralizing from a single misquotation. I've rarely encountered dogmatism from pythonistas, as most of them are too busy getting stuff done.
- chairface 17y ago
  Well, for me, it is a good point. For some reason it's just much easier for me to remember a particular language's way of doing something when there's only one way. Also, I'm a little obsessive about my code consistency, so I dislike having to remember that I've been using Array#size instead of Array#length, for instance. Now, these are obviously not necessarily applicable to anyone else. However, I do feel like I can say that having only one way to do simple things is a plus, without being a "religious nutjob". Which is kind of inflammatory of you to say, by the way.
  - petercooper 17y ago
    There's a big difference between a person stating an opinion or a preference, as you have, and a community standard being defined and defended to the hilt. The first is choice; the second is religion. People who blindly defend Python's wacky standards as some sort of community issue are the religious nutjobs, not people like you who merely have a personal preference. So, no, you're not necessarily a religious nutjob. But, yes, it was meant to inflammatory; people who blindly defend groupthink deserve to have their cages shaken from time to time.
mahmud 17y ago
Django vs Rails is like Old Navy vs the GAP. Lisp web development is haute couture; sure, we might need to travel to the ends of the world to fetch silk, velvet, safron and red dyes, feathers of griffins, and we might need to raise our own albino beavers and translucent-neon chimps to harvest for leather, but the end result is a gallant style fit for a high princely court. (It might also involve a slight invasion of neighboring states to capture their sartorial secrets.)
- tptacek 17y ago
  "Lisp web development is haute couture" ie, not actually intended for people to use. Well played!
  - mahmud 17y ago
    It's up to you to take the red pill, or take the chill pill ;-)
- spicyj 17y ago
  Old Navy and the Gap are owned by the same company.
  - mahmud 17y ago
    Thanks for the info, it only supports my argument for their strong similarity: the vast syntaxful conspiracy is real ..
richcollins 17y ago
> the developer is forced to keep business logic and complex constructs separate from the markup Nothing I like better than having options taken away without any upside!
heycarsten 17y ago
There are many ways of doing the same thing in Ruby? I guess that's true to some extent but I'm not really sure why it's a problem? ['cat', 'dog'] %w[ cat dog ] Although these are not technically the same ... lambda { } proc { } Proc.new { } string.match(/regex/) string =~ /regex/ object.is_a?(Thing) Thing === object hash.merge!(hash) hash.update(hash) Anyways, I'm not a Python programmer, but I can say (with regards to Ruby) when you are used to the language it feels right. Why can't we just all get along and not troll the shit out of each-other?

46 points by foobar2k 17y ago

"Python vs. Ruby (Perl’s Ugly Sister)...This makes the Ruby syntax look like someone emptied all the symbols from the keyboard into a shotgun and shot them into your face." It's amazing watching the python web development community develop, nurture and encourage so much mindless trolling. It has turned reddit completely septic and now this garbage is on the front page here? Sigh.

deleted 17y ago
[deleted]
tvon 17y ago
"It's amazing watching the python web development community develop, nurture and encourage so much mindless trolling." Where are you seeing this? There are a fair number of Django and Python posts on HN and this is the first I've read that I can remember any such trolling.
- carbon8 17y ago
  "on HN" Indeed, but even here it has been increasing. This made it to #2 within a half hour of posting. Even watching this thread you can see people driving through down modding even mdasen's post. Another recently popular blatant nonsensical anti-rails/pro-django troll that comes to mind was the "Magic Sucks, Django Rocks!" submission: http://news.ycombinator.com/item?id=596833 http://news.ycombinator.com/item?id=596833
foobar2k 17y ago
The article was meant to address transition points from django to rails not start a flamewar. I was never encouraged by anyone to "troll", this is from my personal experiences. There's no conspiracy theory here.
- olifante 17y ago
  As a pythonista who likes ruby, I think your "Perl's ugly sister" comments were a shot in the foot and detracted from the rest of your argument, which concentrates on rails and has little to do with Ruby itself.
  - berntb 17y ago
    Frankly, I'm quite used to see this kind of trolling spam about Perl. You could answer by asking after specific problems with "Perl Best Practices" or what can top e.g. Moose, but language wars (+)? I AM able to grow a beard.... This group of scripting languages seems really similar in functionality and usability today (so if I change environment, I'd probably go functional). The large difference seems to be in the cultures around them... (+) I'm all for editor wars, of course! :-)
immad 17y ago
Oh come on, it was funny. You need to lighten up a bit. He gives points on both sides. I do only Ruby and I get what he means.
- petercooper 17y ago
  What does he mean then? I've looked at quite a bit of Python and Ruby source code and Python uses square brackets, periods, mathematical symbols, parentheses, and colons in similar ways. Indeed, a method definition in Ruby uses fewer symbols (no need for the colon on the end, or even the parentheses, although that's against common Ruby style). Python even makes nonsense like using double underscores in method names obligatory. Or how about Python's obligatory parentheses on all method calls? How is Ruby really more "line noise" than Python? Seriously. Sure, Ruby allows you to be more lax than Python and write poor, "line noisy" code, but good Ruby is no more "line noise" than good Python.
  - sri 17y ago
    ruby uses < (less than) for inheritance; also regular expressions start & end with / (slash). you have %W, %w for arrays and %q, %Q for string. things like "class << self ..." looks weird to those new to ruby. also stuff like "a ||= ...". and of course pre-pending '@' for instance variables and '@@' for class variables. also when i use regexps in ruby i then say "/re(g)ex/ =~ 'string' && $1". in python that would be multiple statements: "m = re.match('re(g)ex', 'string'); m.group(1)" in python existing syntax (or more familiar syntax) is used to accomplish all the above.
    - tptacek 17y ago
      I never use %w for arrays and I never use %Q for strings. After years of schlepping through Python's regular expression support --- support not dissimilar from the regex support C++ has --- /regexes/ are a gift from god. Also, your Ruby vs. Python regex examples aren't even equivalent.
    - petercooper 17y ago
      Sigils on variables are a good point. This is an area where I think Python wins out. Dependence on "self" all over the place is irritating at first but ultimately quite comforting - especially when you wonder whether you're going to screw up your attributes when you use the same name for a local variable in your Ruby method ;-) But on inheritance - you have to put the class name in round brackets in Python, no? That's 2 characters to Ruby's 1. Stuff like a ||= shouldn't be considered Ruby-specific noise as Python also has the same idiom as in a += and a -=, just not with ||. || is arguably noise over "or" but it shouldn't seem like cryptic noise with any sort of experience of C, C++, Java, JavaScript, or almost any other mainstream language. Further, that Ruby code of yours does seem more Perlish than Rubyish, but I suspect this is because Ruby style is gradually shifting away from Perl-like styles to more idiomatic approaches. For example, I'd probably choose 'string'[/re(g)ex/, 1] or if I was trying to be "proper" then something like m = string.match(/re(g)ex/); m[1] (or potentially use Regexp#match, but I far prefer String#match). I see those solutions more typically than those you present - and the latter is quite like your Python example - but.. TMTOWTDI and that's Ruby's greatest asset :)
olifante 17y ago
What the hell are you talking about? This is ONE article written by ONE person and suddenly it's the Python community's fault for allowing it to exist? Spare me. This victimization technique should added to the list of Logical Fallacies, if it isn't already there.

look_lookatme 17y ago

What does this article say that hasn't been said before? This stuff just isn't interesting anymore.

fiaz 17y ago
What this article says to me is: 1) there exists multiple frameworks that are independently excellent 2) some of the best minds in both worlds have nothing better to do other than to take sides in meaningless discussions
- stcredzero 17y ago
  some of the best minds in both worlds have nothing better to do other than to take sides in meaningless discussions That and some unsubtle flirting with language wars and trolly word choice is exploitable for linkbait and HN karma.

sreque 17y ago

It is fairly easy to avoid symbol soup in ruby. First, don't use global variables. I'm perfectly OK with global variables sticking out and looking ugly. Second, use the English module packaged with Ruby if you find yourself using Perl-like special global variables a lot. I very rarely use them and so never need to use the module. Finally, use accessor methods to work with instance variables instead of accessing them directly. This also makes it easier to add logic to handle your instance variables without having to rewrite or break any code. If you follow these three steps alone, you will have about the same amount of symbol soup as you would in python, which is almost none. (By the way, I am also a fan of both python and ruby and think they are both great languages).

mdasen 17y ago

In the Rails world, the layer which generates the final markup sent to the browser is called the View layer. In a Rails View, you can chuck as much rails code as you like in amongst your markup. Some of the early sites I worked on many years ago were written in PHP, which had the same idea. Um. . . Sure, you can put any logic you want in a Rails template, but people don't. Rails applications tend to have a nice separation of layout and application logic. Django really likes to constrain users here - not even letting them use a full "if" statement. It's really unfair to just say Rails == Unmaintainable PHP. PHP often becomes that way because there is no immediate way of separating the code. Smarty and others can force you, but both Rails and Django put a really obvious place to put your app logic and developers tend to respect that. Part of this is just how much rope do you give a developer and it's fair to say that one shouldn't give developers that much leeway. However, it's wrong to just equate the two. Multiple Apps in a Project Really, neither framework (or any code) is as pluggable into random situations as we programmers would like. The author suggests that you can use models from different applications in Django. That sounds cooler than it is. They're all running off the same database and in the same project. Really, what Rails creates are projects in Django-speak. And the "apps" convention in Django doesn't help you in development. It helps in organization sometimes - especially the admin interface - but it isn't some spectacular thing where you can just reuse random code in a way that you can't with Rails. Well, I take that back, there is one way that is really nice: namespacing. You can have a blog app that has an Entry and Category model without having to name it BlogEntry and BlogCategory because it would conflict with your Category model for, say, a real estate part of your app. And that is helpful in a way that Rails doesn't solve nicely. However, for the most part Rails and Django provide decently equal utility in this area, they just name the things differently. URL Routing Django's routing is really verbose. You have to specify each route you want. Rails has a bunch of shortcuts for common cases (REST as well as :controller/:action/:id). In a way, this is just the explicit vs. implicit thing. Django makes you explicitly state your URLs while Rails will let you state them, but you don't have to should you like the defaults. The Django folk say that it takes very little time to write routes (true) and that one should be thoughtful when making URLs (also true). But sometimes it just feels tedious. Really, it's just a matter of preference. Ruby (Perl’s Ugly Sister) This is kinda low at some points (why I went to it last - I don't like dwelling on such poor arguments). Ruby doesn't actually use that many symbols ala Perl. All variables are done without symbols; I think strings built as "#{var} is cool" are easier to understand than "%(var)s is cool" % {'var': var}. And it isn't like Python doesn't have weird things like "/".join(list). Really, my beef with Ruby would be how easy (and common) it is to add methods to ancestors without really making it clear. As you start adding methods to Object, you can get yourself into a position where Python's explicitness is really nice. However, when you want to get something done, Ruby can be nice in that respect. It's like having a circular saw: really good for both cutting wood and cutting your hand off. Likewise, Python's mixins are put onto attributes of the model - so that you have things like house.photo.url rather than house.photo_url (although Django did create the second for a long time). That makes it very clear what you're adding while if you say "acts_as_nested_set" in Rails, you don't immediately see which methods are being added. Ruby's problems aren't really syntactic, but it can have things that one could define as problems. -- I've put out two sites in Django and one in Rails and at this point I'm developing two projects in Rails. The Django community is really smart and understated and I still read a lot (smart information translates well to anything), but Django just doesn't see the same pace of development that Rails does. Even something simple such as following reverse foreign keys isn't implemented in Django. Yep, if you try Entry.objects.all(select_related="comments") it will just silently fail (how's that for letting errors pass silently that shouldn't!). And it is difficult and Malcom has way more on his plate than any normal person could even conceive of, but. . . it's still missing. And the Rails community has calmed down a bit, the Merb camp seems to be adding nicely to Rails 3, the Rails framework covers so many more edge cases than it used to as well as just seeming more reliable, and deployment has really stepped up with Passenger. Django is a wonderful piece of software with great features and really smart, considerate people using it. It just isn't seeing as great a push toward little simplifications for more edge cases in the way that Rails has been. Frankly, they're so much alike in all the meaningful ways - I think that's why I have such an easy time wrapping my head around both. Eh, I have to get dinner.

petercooper 17y ago

Sorry Pythonistas, but whenever you say that having "only one way" to do something is a good point (and many have said this), you sound like religious nutjobs. There's more than one good and obvious way to do anything worth doing, be it giving birth, building a bridge, adding two numbers together, or developing algorithms in a programming language. I like Python on many levels - particularly the indentation - but the religious-ness of the philosophy and language design is off-putting in so many other ways.

jjs 17y ago
> I like Python on many levels - particularly the indentation - but the religious-ness of the philosophy and language design is off-putting in so many other ways. I think you're overgeneralizing from a single misquotation. I've rarely encountered dogmatism from pythonistas, as most of them are too busy getting stuff done.
chairface 17y ago
Well, for me, it is a good point. For some reason it's just much easier for me to remember a particular language's way of doing something when there's only one way. Also, I'm a little obsessive about my code consistency, so I dislike having to remember that I've been using Array#size instead of Array#length, for instance. Now, these are obviously not necessarily applicable to anyone else. However, I do feel like I can say that having only one way to do simple things is a plus, without being a "religious nutjob". Which is kind of inflammatory of you to say, by the way.
- petercooper 17y ago
  There's a big difference between a person stating an opinion or a preference, as you have, and a community standard being defined and defended to the hilt. The first is choice; the second is religion. People who blindly defend Python's wacky standards as some sort of community issue are the religious nutjobs, not people like you who merely have a personal preference. So, no, you're not necessarily a religious nutjob. But, yes, it was meant to inflammatory; people who blindly defend groupthink deserve to have their cages shaken from time to time.

mahmud 17y ago

Django vs Rails is like Old Navy vs the GAP. Lisp web development is haute couture; sure, we might need to travel to the ends of the world to fetch silk, velvet, safron and red dyes, feathers of griffins, and we might need to raise our own albino beavers and translucent-neon chimps to harvest for leather, but the end result is a gallant style fit for a high princely court. (It might also involve a slight invasion of neighboring states to capture their sartorial secrets.)

tptacek 17y ago
"Lisp web development is haute couture" ie, not actually intended for people to use. Well played!
- mahmud 17y ago
  It's up to you to take the red pill, or take the chill pill ;-)
spicyj 17y ago
Old Navy and the Gap are owned by the same company.
- mahmud 17y ago
  Thanks for the info, it only supports my argument for their strong similarity: the vast syntaxful conspiracy is real ..

richcollins 17y ago

> the developer is forced to keep business logic and complex constructs separate from the markup Nothing I like better than having options taken away without any upside!

heycarsten 17y ago

There are many ways of doing the same thing in Ruby? I guess that's true to some extent but I'm not really sure why it's a problem? ['cat', 'dog'] %w[ cat dog ] Although these are not technically the same ... lambda { } proc { } Proc.new { } string.match(/regex/) string =~ /regex/ object.is_a?(Thing) Thing === object hash.merge!(hash) hash.update(hash) Anyways, I'm not a Python programmer, but I can say (with regards to Ruby) when you are used to the language it feels right. Why can't we just all get along and not troll the shit out of each-other?