4 ms·

Depending on your point of view, this is a perfect example of either what makes ruby so amazing or so awful. I don't know of another language that gives you th

Depending on your point of view, this is a perfect example of either what makes ruby so amazing or so awful. I don't know of another language that gives you the power to so concisely potentially screw yourself in such a creative way.

andreyf 16y ago
Let's not be too eager to accept the "tradeoff metaphor". Just because something is powerful doesn't mean it can't be safe. I just got a handheld vacuum that has no safety mechanisms: no latches to disable the power button when it's folded shut, no kill switches when I take it apart. I can fold over the nozzle, take off the dust holder, and turn it on. I would never need to operate it in that way (unless I was using it as an air pump, which I could, now that I think of it), but it doesn't need any complexity to be safe, because safety is part of its design. Similarly, a VM could expose a REST-ful API to its objects without needing to have any of the things which people find "unsafe" about Ruby (regardless of how valid those complaints are).
- cageface 16y ago
  The problem with sharp edges in programming languages is that you might be perfectly sane and careful on your own but you must also trust everybody else you code with to not only exercise the same restraint but to also point their sharp edges in roughly the same direction.
  - ericb 16y ago
    You could argue it pushes the problem up the stack to the hiring stage.
    - patio11 16y ago
      It pushes the problem to the hiring stage at the company which wrote the OSS pulled in by the gem pulled in by the gem pulled in by the update to your Twitter integration plugin. For kicks, go open script/console, type [].methods.size, and create a passing test for that number. It will fail, eventually. The code that kills it may surprise you.
      - ericb 16y ago
        This is an interesting idea, and I will try it. Added methods mainly gets you if there is a name collision, it seems to me. Changing core methods, which is also possible, scares the bejeezus out of me.
        pig 16y ago
        scares the bejeezus out of me as it should.
- rauljara 16y ago
  Don't get me wrong, I fall squarely on the side that Ruby's power is well worth it's danger. But let's not kid ourselves, monkey-patching Object is dangerous. In this example, exposing all of an object's methods to the web means that anyone could further modify whatever object you stuck up there, adding whatever methods they wanted. Yes, you could expose it to the web in a safe manner, but that would be a lot more work. Ruby holds out that simple, easy, even elegant monkey-patching solution to tempt you in ways that you have to be really careful about.
  - andreyf 16y ago
    Don't get me wrong, I fall squarely on the side that Ruby's power is well worth it's danger. Would you hold the same view if you were tech lead of a team of a dozen engineers who've never worked together and loved monkey patching? You can agree to not monkey patch simply by saying "don't monkey patch" and hope everyone follows it, but then you'd probably need to and putting social processes in place to make sure people don't do it (e.g. code review), you can pick a platform that doesn't allow it, or you can recompile the Ruby runtime you use to disallow allow monkey patching. Another option would be to automate some kind of monkey-patch detection in a staging VM that keeps a list of monkey patches in your code and publishes it to an architecture doc page. Then you can either call that list "tech debt" and strive to constantly refactor the code to get rid of monkey patches, or you can make it part of whatever communication the team does to discuss/agree on what monkey patches are acceptable to use globally in the system. In that case, you also have to make sure that whatever process is in place for deciding yay/nay on keeping a monkey patch treats everyone's contributions fairly. Etc, etc. All in all, monkey patching is just one example of changes that affect the VM globally. Personally, I prefer that whatever complexity comes with global changes be dealt with by the programming team, not the VM designers (which is what the JVM often does), but I can certainly imagine a team where everyone is making global changes and nobody is aware of the complexity such changes bring to a project. Then everything simply stalls while people bitch at each other about X's code breaking Y's code because of dependency Z, the business guys start yelling because deadlines are missed, and the entire project goes to hell in a handbasket.
ErrantX 16y ago
uh, pretty much every other web able programming language will let you do exactly the same... php, python etc.
- steveklabnik 16y ago
  The key phrases were 'concise' and 'creative'. Of course you can expose an object's methods in any language, but not many will let you do it by monkeypatching Object with a two-line method.

andreyf 16y ago

Let's not be too eager to accept the "tradeoff metaphor". Just because something is powerful doesn't mean it can't be safe. I just got a handheld vacuum that has no safety mechanisms: no latches to disable the power button when it's folded shut, no kill switches when I take it apart. I can fold over the nozzle, take off the dust holder, and turn it on. I would never need to operate it in that way (unless I was using it as an air pump, which I could, now that I think of it), but it doesn't need any complexity to be safe, because safety is part of its design. Similarly, a VM could expose a REST-ful API to its objects without needing to have any of the things which people find "unsafe" about Ruby (regardless of how valid those complaints are).

cageface 16y ago
The problem with sharp edges in programming languages is that you might be perfectly sane and careful on your own but you must also trust everybody else you code with to not only exercise the same restraint but to also point their sharp edges in roughly the same direction.
- ericb 16y ago
  You could argue it pushes the problem up the stack to the hiring stage.
  - patio11 16y ago
    It pushes the problem to the hiring stage at the company which wrote the OSS pulled in by the gem pulled in by the gem pulled in by the update to your Twitter integration plugin. For kicks, go open script/console, type [].methods.size, and create a passing test for that number. It will fail, eventually. The code that kills it may surprise you.
    - ericb 16y ago
      This is an interesting idea, and I will try it. Added methods mainly gets you if there is a name collision, it seems to me. Changing core methods, which is also possible, scares the bejeezus out of me.
      - pig 16y ago
        scares the bejeezus out of me as it should.
rauljara 16y ago
Don't get me wrong, I fall squarely on the side that Ruby's power is well worth it's danger. But let's not kid ourselves, monkey-patching Object is dangerous. In this example, exposing all of an object's methods to the web means that anyone could further modify whatever object you stuck up there, adding whatever methods they wanted. Yes, you could expose it to the web in a safe manner, but that would be a lot more work. Ruby holds out that simple, easy, even elegant monkey-patching solution to tempt you in ways that you have to be really careful about.
- andreyf 16y ago
  Don't get me wrong, I fall squarely on the side that Ruby's power is well worth it's danger. Would you hold the same view if you were tech lead of a team of a dozen engineers who've never worked together and loved monkey patching? You can agree to not monkey patch simply by saying "don't monkey patch" and hope everyone follows it, but then you'd probably need to and putting social processes in place to make sure people don't do it (e.g. code review), you can pick a platform that doesn't allow it, or you can recompile the Ruby runtime you use to disallow allow monkey patching. Another option would be to automate some kind of monkey-patch detection in a staging VM that keeps a list of monkey patches in your code and publishes it to an architecture doc page. Then you can either call that list "tech debt" and strive to constantly refactor the code to get rid of monkey patches, or you can make it part of whatever communication the team does to discuss/agree on what monkey patches are acceptable to use globally in the system. In that case, you also have to make sure that whatever process is in place for deciding yay/nay on keeping a monkey patch treats everyone's contributions fairly. Etc, etc. All in all, monkey patching is just one example of changes that affect the VM globally. Personally, I prefer that whatever complexity comes with global changes be dealt with by the programming team, not the VM designers (which is what the JVM often does), but I can certainly imagine a team where everyone is making global changes and nobody is aware of the complexity such changes bring to a project. Then everything simply stalls while people bitch at each other about X's code breaking Y's code because of dependency Z, the business guys start yelling because deadlines are missed, and the entire project goes to hell in a handbasket.

ErrantX 16y ago

uh, pretty much every other web able programming language will let you do exactly the same... php, python etc.

steveklabnik 16y ago
The key phrases were 'concise' and 'creative'. Of course you can expose an object's methods in any language, but not many will let you do it by monkeypatching Object with a two-line method.