5 ms·

The title made me nervous that this would be run-of-the-mill fanboy garbage. But I trust the author (Alex Martelli), so I read it, and I'm glad I did. It's reas

The title made me nervous that this would be run-of-the-mill fanboy garbage. But I trust the author (Alex Martelli), so I read it, and I'm glad I did. It's reasonable and sane. My two big take-away points: 1) It's very nearly a wash. Ruby and Python are so close together (beneath any superficial differences) that distinguishing is almost an exercise in futility. 2) The key thing about Ruby he doesn't like is its "TOTAL, unbridled "dynamicity", including the ability to "reopen" any existing class, including all built-in ones, and change its behavior at run-time." To M's way of thinking, this makes Ruby less "suited for use in large production applications" and more suited for "tinkering." I don't buy the argument myself, but I will admit that when I first started learning about Ruby, everything I read went on and on about how cool it was that you could open everything up and play. But as I read more, I discovered that the community seems pretty heavily tilted against monkey-patching now. (I may be wrong about this, but it's my impression.) I don't think that means Ruby is for tinkering only, but it does suggest that Martelli's concern is legitimate. He also offers some nice pasta recipes along the way. (So much so, that now I'm hungry.)

rjurney 16y ago
The fact that anyone at any point can monkey patch any built-in is a potential liability for large teams, with average programmers. It must be addressed by culture and code review that you may or may not have. Still worth it though :)
- jshen 16y ago
  I've never bought the idea that the opposite is a better trade off because it comes with costs too. Have you ever worked with a bunch of mediocre java programers? Heaven forbid they make an interface that isn't well thought out and needs to be changed later!
  - rjurney 16y ago
    That extreme is also terrible. Python is somewhere in between.
    - jshen 16y ago
      if ruby is an extreme to the left, and java an extreme to the right, then python is also extreme to the left. The difference between python and ruby in dynamicity is really small. Python is not in the middle of ruby and java. Python is virtually on top of ruby.
      - andybak 16y ago
        A fair point. Maybe 'optimum' would be a more useful concept here than 'centre'... I see Python's position on the dynamicity (ugh) spectrum is in line with it's philosophy on readability. (On a side note - your definition of 'extreme' rather depends on what outliers you have. I do love it when the US media refers to the Democrats as 'left of center' ;)
        jshen 16y ago
        yup, republican and java are in the same camp ;) On a serious note, I've been doing ruby as my job for about 5 years and I work at a giant corporation with a few hundred programmers. In those 5 years I've never been bitten by someone changing a core class that breaks my code. Maybe 3 times I've been bitten by someone changing a non core class, and it usually takes me about an hour or two to resolve it. So that's maybe 6 hours in 5 years where I've lost time due to this, but the amount of time it has saved me is far larger than this.
        andybak 16y ago
        That sounds like an interesting big Ruby gig that would be a good story to tell the anti-dynamic languages FUD brigade. You should blog :)
- wmoxam 16y ago
  Are there many ruby app built by large teams? In my experience, teams building Ruby apps tend to be much smaller than teams building Java apps .. That said, this is a problem for any libraries that you might want to include, you have to trust that the authors followed conventions and didn't do any thing 'evil'. Ruby Rewrite (http://rewrite.rubyforge.org/ http://rewrite.rubyforge.org/) was conceived to specifically avoid this sort of problem.
  - sunkencity 16y ago
    The best software is built by small teams.
- derefr 16y ago
  In what situation is it actually a good idea to employ a large number of bad programmers, rather than a small number of good ones? We shouldn't be making trade-offs for the sake of bad ideas ;)
  - techiferous 16y ago
    ...and all it takes is one rogue or bad programmer to mess up the code base.
    - derefr 16y ago
      ...in either scenario. During code review, however, I'd expect that the good programmers would reach much more strongly to the rogue commits than the mediocre programmers would.
  - acdha 16y ago
    There's a distinction to be made between preventing risky behaviour and relying only on a programmer's good judgement to avoid mistakes. Even if your team is solely good programmers there's a lot to be said for discouraging unsafe behaviour by default since anyone can have a bad day, distraction, etc. I view this situation as somewhat analogous to having guards on power tools: even a highly skilled operator doesn't want to rely on always doing something perfectly.
    - derefr 16y ago
      The nice thing about code is that (when version controlled) all mistakes can be fixed retroactively. As long as two programmers aren't having a bad day at once, pairing will catch "all" errors. As long as all your programmers aren't having a bad day at once, code review will catch "all" errors again. ;)
      - wariola 16y ago
        This is why you need to automate peer review http://www.parasoft.com http://www.parasoft.com
cageface 16y ago
Both languages offer the unvigilant programmer plenty of opportuities to shoot off his foot. If you're really concerned about this you should take a look at scala. I'm amazed at how much easier it is for me to maintain my own scala code than either ruby or python.
- jshen 16y ago
  and so much harder for me to maintain someone else's scala code. It feels like statically typed perl, but that's just mho.
  - cageface 16y ago
    It is possible to write very cryptic scala code. Mine isn't, but neither was my perl.
  - whakojacko 16y ago
    Yea, you can make scala look like haskell, java, or perl with relative ease. Up for debate whether thats a good thing or not.
  - sreque 16y ago
    At least with version 2.7, I actually really enjoyed looking at the Scala standard library code when the documentation wasn't sufficient for my needs. That's no knock on the scala documentation either, as I frequently look at the JDK standard library source code too. I've also had a couple of similarly positive experiences digging around the Lift code. What other "someone else's" Scala code have you actually had to look at and maintain that you had problems with? In my experience, I only have a hard time understanding Scala code when it is doing something I'm conceptually unfamiliar with, usually something in the functional world that I know little or nothing about.
    - jshen 16y ago
      it's been a while so I don't remember the specifics but it was code for dealing with json in a lift code base.
DanielRibeiro 16y ago
About point 2: the author is probably ignorant of ast module (http://docs.python.org/library/ast.html http://docs.python.org/library/ast.html), which allows the programmer to take any ast and recompile it to anything he/she wants (in runtime, unlike Lisp macros, but alike parse tree and ruby2ruby in ruby). This feature allows you to transform things like "1, minute" into "Minute(1)", enabling dsls, and "wrecking havoc" all over. In ruby, you don't have to do this, as there are simpler and less powerful metaprogramming tools. So yeah. Just because you have a shotgun, it doesn't mean you can't use it to kill a fly. Of course, the really important question is not if you can, but if you should. And it is always better that this decision is left for the users of the language than to its creators.
- jacobian 16y ago
  So "the author" is Alex Martelli, a long-time Python user, contributor, and winner of the 2006 Frank Willison award which is given each year for outstanding contribution to the Python community. I highly doubt he's "ignorant" of anything when it comes to Python... A better theory is this article is from 2003, but the ast module was added in Python 2.6, which was released in 2008. (I agree with everything you've said in the second and third paragraphs, but, man, try to give people a little credit before you assume they're ignorant, 'k?)
  - DanielRibeiro 16y ago
    Thanks for the info. I was ignorant of the author and post date. I seriously did not want to imply (the incorrect fact) that the author was ignorant in general, but of a single matter (which is kinda unknown, so I'd expect most be to be oblivious to it). I am equaly sorry for the bad choice of words...
- didip 16y ago
  It takes efforts to write a simple Transformer using ast. Along the way of making one, your instinct will tell you that doing so is a bad idea, probably. In Ruby, meta-programming is always powerful and always so easy to use. I don't have problem using these methods, but it pains me when some crappy monkey-patching-flavored gem (For example, cache-money) decided to bite me intermittently. Or when debugging the code of some kick-ass-ninja-rockstar programmer where he decided to generate methods using both class_eval and instance_eval (along the way, generating the "def statements" using string interpolation) inside a module that supposed to be injected into ActiveRecord object. I do agree with your last paragraph completely. The real ninja is capable of stopping himself from beheading anyone he sees just because he can.
stevefink 16y ago
Re 2): With great power comes great responsibility.
xal 16y ago
We run probably one of the largest Ruby production systems that has ever been made and the dynamism and "monkey patching" are used daily to skillfully make the language better and better over time for the tasks that we solve. It's absolutely crucial to teams that internalize it's power and pitfalls.
- techiferous 16y ago
  "one of the largest Ruby production systems that has ever been made" As an aside, I worked on a very large Ruby app (built by about a dozen developers over the course of years) and then later worked on another very large Ruby app of similar size. One of the employees there remarked that it was the largest Rails app built. I think the people who write very large Ruby apps tend to be very quiet about it (no blogs, no open-source, less community participation, etc.) so that if you're one of the ones writing a very large Ruby app you think yours is the largest. :)
  - sammyo 16y ago
    Lol, I work on a Ruby app that is entirely internal and processes an incredible volume of information. The key here was the ease of adding a few key C modules.
  - nkassis 16y ago
    I can fully agree about the quietness of developers working on large ruby app considering I work on such an app but were not big on advertising it yet.
- nupeter 16y ago
  Cool. What's the site?
- didip 16y ago
  I was about to ask if you work for Twitter, but then I read your bio. I like Shopify, all the shops built with it look real slick.
  - 16y ago
loewenskind 16y ago
If you want to know about Monkey patching visit the Smalltalk community. They've been doing it a lot longer.
dimituri 16y ago
If only there was a tool to fix core objects that were tinkered with. Something like... wait. Monkey patching! But seriously, at his Q&A session on EuRuKo 2010 Matz mentioned that monkey patching issues are going to be addressed in Ruby 2.0. http://nuclearsquid.com/writings/euruko-day2.html http://nuclearsquid.com/writings/euruko-day2.html
moron4hire 16y ago
My impression of the Ruby community, especially the OSS part of it, was that they were explicitly more about tinkering than enterprise. Certainly characters like _why were in that camp. In regards to monkey-patching, while I'm not a Ruby programmer by any means, I sorely feel its absence in other languages. It's in JavaScript (expando objects as well as being able to override and overwrite built-in methods of existing types), and to some extent available in C# (extension methods are a sort-of expando object, but there is very little ability to overwrite a method). Like operator overloading, sure, don't build a project completely off of it (I'm looking at you, C++'s iostream), but when you need it, damn you need it. I'm still delving into Python (late to the party, whatever), but I definitely use Python in much more of a tinkering fashion, so monkey-patching is something I would desire in the language.
- telemachos 16y ago
  My impression of the Ruby community, especially the OSS part of it, was that they were explicitly more about tinkering than enterprise. Certainly characters like _why were in that camp. I don't entirely disagree with the larger sentiments, but I worry about the tone of the word 'tinker'. That is, the Ruby world is full of playful characters, and often displays a spirit that is far from corporate. However, many Ruby (and RoR) apps are also serious businesses at this point. There are also many libraries that don't charge money, do exhibit that playful or exuberant spirit, but also provide hard-core real-world functionality (e.g., Nokogiri). tl;dr The word 'tinker' is a bit trivializing (perhaps unintentionally on Martelli's part). The division between 'tinker' and 'enterprise' doesn't fully or properly cut up the problem space. It's a binary view of a multi-faceted world. (For whatever it's worth, this is my view as someone on the outside of this whole situation. I use Ruby and Perl about equally, primarily for systems administration and personal projects.)
  - moron4hire 16y ago
    I agree completely. I tend to dislike the phrase "enterprise development" anyway, because it implies that somehow our programming is suddenly different just because a company uses it. But, I try to write for my audience.
joe_the_user 16y ago
As I recall, Python actually has even more detailed meta-programming abilities if you look around in it; in Python but not Ruby, a function can scan up the calling stack and determine the name a caller used for an object that the function was passed (which sounds crazy but could be nice for a DSL). It's just that Python hasn't ever had an ethos of monkey-patching.

rjurney 16y ago

The fact that anyone at any point can monkey patch any built-in is a potential liability for large teams, with average programmers. It must be addressed by culture and code review that you may or may not have. Still worth it though :)

jshen 16y ago
I've never bought the idea that the opposite is a better trade off because it comes with costs too. Have you ever worked with a bunch of mediocre java programers? Heaven forbid they make an interface that isn't well thought out and needs to be changed later!
- rjurney 16y ago
  That extreme is also terrible. Python is somewhere in between.
  - jshen 16y ago
    if ruby is an extreme to the left, and java an extreme to the right, then python is also extreme to the left. The difference between python and ruby in dynamicity is really small. Python is not in the middle of ruby and java. Python is virtually on top of ruby.
    - andybak 16y ago
      A fair point. Maybe 'optimum' would be a more useful concept here than 'centre'... I see Python's position on the dynamicity (ugh) spectrum is in line with it's philosophy on readability. (On a side note - your definition of 'extreme' rather depends on what outliers you have. I do love it when the US media refers to the Democrats as 'left of center' ;)
      - jshen 16y ago
        yup, republican and java are in the same camp ;) On a serious note, I've been doing ruby as my job for about 5 years and I work at a giant corporation with a few hundred programmers. In those 5 years I've never been bitten by someone changing a core class that breaks my code. Maybe 3 times I've been bitten by someone changing a non core class, and it usually takes me about an hour or two to resolve it. So that's maybe 6 hours in 5 years where I've lost time due to this, but the amount of time it has saved me is far larger than this.
        andybak 16y ago
        That sounds like an interesting big Ruby gig that would be a good story to tell the anti-dynamic languages FUD brigade. You should blog :)
wmoxam 16y ago
Are there many ruby app built by large teams? In my experience, teams building Ruby apps tend to be much smaller than teams building Java apps .. That said, this is a problem for any libraries that you might want to include, you have to trust that the authors followed conventions and didn't do any thing 'evil'. Ruby Rewrite (http://rewrite.rubyforge.org/ http://rewrite.rubyforge.org/) was conceived to specifically avoid this sort of problem.
- sunkencity 16y ago
  The best software is built by small teams.
derefr 16y ago
In what situation is it actually a good idea to employ a large number of bad programmers, rather than a small number of good ones? We shouldn't be making trade-offs for the sake of bad ideas ;)
- techiferous 16y ago
  ...and all it takes is one rogue or bad programmer to mess up the code base.
  - derefr 16y ago
    ...in either scenario. During code review, however, I'd expect that the good programmers would reach much more strongly to the rogue commits than the mediocre programmers would.
- acdha 16y ago
  There's a distinction to be made between preventing risky behaviour and relying only on a programmer's good judgement to avoid mistakes. Even if your team is solely good programmers there's a lot to be said for discouraging unsafe behaviour by default since anyone can have a bad day, distraction, etc. I view this situation as somewhat analogous to having guards on power tools: even a highly skilled operator doesn't want to rely on always doing something perfectly.
  - derefr 16y ago
    The nice thing about code is that (when version controlled) all mistakes can be fixed retroactively. As long as two programmers aren't having a bad day at once, pairing will catch "all" errors. As long as all your programmers aren't having a bad day at once, code review will catch "all" errors again. ;)
    - wariola 16y ago
      This is why you need to automate peer review http://www.parasoft.com http://www.parasoft.com

cageface 16y ago

Both languages offer the unvigilant programmer plenty of opportuities to shoot off his foot. If you're really concerned about this you should take a look at scala. I'm amazed at how much easier it is for me to maintain my own scala code than either ruby or python.

jshen 16y ago
and so much harder for me to maintain someone else's scala code. It feels like statically typed perl, but that's just mho.
- cageface 16y ago
  It is possible to write very cryptic scala code. Mine isn't, but neither was my perl.
- whakojacko 16y ago
  Yea, you can make scala look like haskell, java, or perl with relative ease. Up for debate whether thats a good thing or not.
- sreque 16y ago
  At least with version 2.7, I actually really enjoyed looking at the Scala standard library code when the documentation wasn't sufficient for my needs. That's no knock on the scala documentation either, as I frequently look at the JDK standard library source code too. I've also had a couple of similarly positive experiences digging around the Lift code. What other "someone else's" Scala code have you actually had to look at and maintain that you had problems with? In my experience, I only have a hard time understanding Scala code when it is doing something I'm conceptually unfamiliar with, usually something in the functional world that I know little or nothing about.
  - jshen 16y ago
    it's been a while so I don't remember the specifics but it was code for dealing with json in a lift code base.

DanielRibeiro 16y ago

About point 2: the author is probably ignorant of ast module (http://docs.python.org/library/ast.html http://docs.python.org/library/ast.html), which allows the programmer to take any ast and recompile it to anything he/she wants (in runtime, unlike Lisp macros, but alike parse tree and ruby2ruby in ruby). This feature allows you to transform things like "1, minute" into "Minute(1)", enabling dsls, and "wrecking havoc" all over. In ruby, you don't have to do this, as there are simpler and less powerful metaprogramming tools. So yeah. Just because you have a shotgun, it doesn't mean you can't use it to kill a fly. Of course, the really important question is not if you can, but if you should. And it is always better that this decision is left for the users of the language than to its creators.

jacobian 16y ago
So "the author" is Alex Martelli, a long-time Python user, contributor, and winner of the 2006 Frank Willison award which is given each year for outstanding contribution to the Python community. I highly doubt he's "ignorant" of anything when it comes to Python... A better theory is this article is from 2003, but the ast module was added in Python 2.6, which was released in 2008. (I agree with everything you've said in the second and third paragraphs, but, man, try to give people a little credit before you assume they're ignorant, 'k?)
- DanielRibeiro 16y ago
  Thanks for the info. I was ignorant of the author and post date. I seriously did not want to imply (the incorrect fact) that the author was ignorant in general, but of a single matter (which is kinda unknown, so I'd expect most be to be oblivious to it). I am equaly sorry for the bad choice of words...
didip 16y ago
It takes efforts to write a simple Transformer using ast. Along the way of making one, your instinct will tell you that doing so is a bad idea, probably. In Ruby, meta-programming is always powerful and always so easy to use. I don't have problem using these methods, but it pains me when some crappy monkey-patching-flavored gem (For example, cache-money) decided to bite me intermittently. Or when debugging the code of some kick-ass-ninja-rockstar programmer where he decided to generate methods using both class_eval and instance_eval (along the way, generating the "def statements" using string interpolation) inside a module that supposed to be injected into ActiveRecord object. I do agree with your last paragraph completely. The real ninja is capable of stopping himself from beheading anyone he sees just because he can.

stevefink 16y ago

Re 2): With great power comes great responsibility.

xal 16y ago

We run probably one of the largest Ruby production systems that has ever been made and the dynamism and "monkey patching" are used daily to skillfully make the language better and better over time for the tasks that we solve. It's absolutely crucial to teams that internalize it's power and pitfalls.

techiferous 16y ago
"one of the largest Ruby production systems that has ever been made" As an aside, I worked on a very large Ruby app (built by about a dozen developers over the course of years) and then later worked on another very large Ruby app of similar size. One of the employees there remarked that it was the largest Rails app built. I think the people who write very large Ruby apps tend to be very quiet about it (no blogs, no open-source, less community participation, etc.) so that if you're one of the ones writing a very large Ruby app you think yours is the largest. :)
- sammyo 16y ago
  Lol, I work on a Ruby app that is entirely internal and processes an incredible volume of information. The key here was the ease of adding a few key C modules.
- nkassis 16y ago
  I can fully agree about the quietness of developers working on large ruby app considering I work on such an app but were not big on advertising it yet.
nupeter 16y ago
Cool. What's the site?
didip 16y ago
I was about to ask if you work for Twitter, but then I read your bio. I like Shopify, all the shops built with it look real slick.
- 16y ago

loewenskind 16y ago

If you want to know about Monkey patching visit the Smalltalk community. They've been doing it a lot longer.

dimituri 16y ago

If only there was a tool to fix core objects that were tinkered with. Something like... wait. Monkey patching! But seriously, at his Q&A session on EuRuKo 2010 Matz mentioned that monkey patching issues are going to be addressed in Ruby 2.0. http://nuclearsquid.com/writings/euruko-day2.html http://nuclearsquid.com/writings/euruko-day2.html

moron4hire 16y ago

My impression of the Ruby community, especially the OSS part of it, was that they were explicitly more about tinkering than enterprise. Certainly characters like _why were in that camp. In regards to monkey-patching, while I'm not a Ruby programmer by any means, I sorely feel its absence in other languages. It's in JavaScript (expando objects as well as being able to override and overwrite built-in methods of existing types), and to some extent available in C# (extension methods are a sort-of expando object, but there is very little ability to overwrite a method). Like operator overloading, sure, don't build a project completely off of it (I'm looking at you, C++'s iostream), but when you need it, damn you need it. I'm still delving into Python (late to the party, whatever), but I definitely use Python in much more of a tinkering fashion, so monkey-patching is something I would desire in the language.

telemachos 16y ago
My impression of the Ruby community, especially the OSS part of it, was that they were explicitly more about tinkering than enterprise. Certainly characters like _why were in that camp. I don't entirely disagree with the larger sentiments, but I worry about the tone of the word 'tinker'. That is, the Ruby world is full of playful characters, and often displays a spirit that is far from corporate. However, many Ruby (and RoR) apps are also serious businesses at this point. There are also many libraries that don't charge money, do exhibit that playful or exuberant spirit, but also provide hard-core real-world functionality (e.g., Nokogiri). tl;dr The word 'tinker' is a bit trivializing (perhaps unintentionally on Martelli's part). The division between 'tinker' and 'enterprise' doesn't fully or properly cut up the problem space. It's a binary view of a multi-faceted world. (For whatever it's worth, this is my view as someone on the outside of this whole situation. I use Ruby and Perl about equally, primarily for systems administration and personal projects.)
- moron4hire 16y ago
  I agree completely. I tend to dislike the phrase "enterprise development" anyway, because it implies that somehow our programming is suddenly different just because a company uses it. But, I try to write for my audience.

joe_the_user 16y ago

As I recall, Python actually has even more detailed meta-programming abilities if you look around in it; in Python but not Ruby, a function can scan up the calling stack and determine the name a caller used for an object that the function was passed (which sounds crazy but could be nice for a DSL). It's just that Python hasn't ever had an ethos of monkey-patching.