4 ms·

To be honest, reading Reg's posts lately you get the impression that this happens all the time. Obviously it does happen a certain amount, hence the various peo

by ionfish 18y ago

To be honest, reading Reg's posts lately you get the impression that this happens all the time. Obviously it does happen a certain amount, hence the various people (quite understandably) complaining about it, but probably not as often as one might start to think, given the number and volume of complaints.

jerf 18y ago
The problem is that when it does happen, you are screwed, hard, and numerous other languages with powerful module systems and powerful metaprogramming and powerful everything-else-that-Ruby-does, and has as many libraries as Ruby (or more), provide a concrete demonstration that you don't need monkeypatching to do awesome things. Also, the mess only gets bigger as you have more and more people using Ruby. That's part of the seductive danger of the monkeypatching approach... it seems to work so well when you have a small community. Unfortunately, it anti-scales; it gets actively worse the larger the community gets. So, you are suffering these difficult and often effectively intractable problems (short of modifying other people's libraries which is not something you should need to do in the general case), and in return for this difficulty you get nothing not provided by numerous other languages without such problems. It's a terrible, terrible trade in the long run. (And the long run is here now.)
- knowtheory 18y ago
  Why are you trolling Ruby for this? There are safe ways to metaprogram Ruby very successfully in an extensible and readable fashion. That's why there's a movement in the Ruby community to kill alias_method_chain for one. Nor is this a problem that scales with community size. There are bad programmers everywhere. If using their libraries causes your project to explode, don't use their code. Rails is fully admitted to be too clever for it's own good, which is why the push to Rails3 and cleaning out the kludges in the Rails code base is so important. That's why the Merb project was getting so much attention in the first place. Never the less, this is still about getting numerous different packages to work together. It's a package dependency problem. Granted Ruby's ability to reopen classes anywhere it likes makes this problem more difficult, but i hardly see this as an indictment of any use of the language. So yes, package management is hard. People should metaprogram responsibly. But that's true in other languages as well. :p
  - raganwald 18y ago
    > It's a package dependency problem. If you solve the package dependency problem, you will be left with the meta-programming collision problem. However, I feel that if you solve the meta-programming collision problem, you will also solve the package dependency problem. Which is the point of this post. I am not saying anything about the size or severity of the two problems, just noting that I think solving one will solve the other.
    - knowtheory 18y ago
      Raganwald, i agree with your identification of this problem. But the anti-Ruby trolling is getting out of control :( (and i don't blame you for that). There are a couple different suggestions people have discussed, but some of them, like selector namespacing, have been languishing in discussion land for years (Matz has been talking about it for a while apparently). This still doesn't solve the case where you have two different plugins or gems that you'd like to use, that require different versions of the same gem. Ruby is open enough to give you enough rope to hang yourself w/ in this case. The alternative is what... just not doing package versioning? That seems like a step backwards too.
      - raganwald 18y ago
        > The alternative is what... just not doing package versioning? That seems like a step backwards too. Imagine that you have lexical scope for changes to global constants. Like Perl's local keyword or Lisp's let. So you can redefine Array and the new definition is only valid within the lexical scope of a block. Code that the block calls does NOT get the new definition, so your code can have one version of Array#sum, my code can have another, and we can freely call each other or call code that doesn't expect Array to have a #sum method. Now thinking about that solution to the meta-programming collision problem, the solution to the gem version problem is also plain: gems can be scoped too, and if I use version 1 of a gem in a block and you use version 2 in a block, only the code within our blocks see the effects of the gems they include. So yes, packages have versions, but the same mechanism that applies lexical scope to meta-programming mediates package version conflicts.

by ionfish 18y ago

jerf 18y ago

The problem is that when it does happen, you are screwed, hard, and numerous other languages with powerful module systems and powerful metaprogramming and powerful everything-else-that-Ruby-does, and has as many libraries as Ruby (or more), provide a concrete demonstration that you don't need monkeypatching to do awesome things. Also, the mess only gets bigger as you have more and more people using Ruby. That's part of the seductive danger of the monkeypatching approach... it seems to work so well when you have a small community. Unfortunately, it anti-scales; it gets actively worse the larger the community gets. So, you are suffering these difficult and often effectively intractable problems (short of modifying other people's libraries which is not something you should need to do in the general case), and in return for this difficulty you get nothing not provided by numerous other languages without such problems. It's a terrible, terrible trade in the long run. (And the long run is here now.)

knowtheory 18y ago
Why are you trolling Ruby for this? There are safe ways to metaprogram Ruby very successfully in an extensible and readable fashion. That's why there's a movement in the Ruby community to kill alias_method_chain for one. Nor is this a problem that scales with community size. There are bad programmers everywhere. If using their libraries causes your project to explode, don't use their code. Rails is fully admitted to be too clever for it's own good, which is why the push to Rails3 and cleaning out the kludges in the Rails code base is so important. That's why the Merb project was getting so much attention in the first place. Never the less, this is still about getting numerous different packages to work together. It's a package dependency problem. Granted Ruby's ability to reopen classes anywhere it likes makes this problem more difficult, but i hardly see this as an indictment of any use of the language. So yes, package management is hard. People should metaprogram responsibly. But that's true in other languages as well. :p
- raganwald 18y ago
  > It's a package dependency problem. If you solve the package dependency problem, you will be left with the meta-programming collision problem. However, I feel that if you solve the meta-programming collision problem, you will also solve the package dependency problem. Which is the point of this post. I am not saying anything about the size or severity of the two problems, just noting that I think solving one will solve the other.
  - knowtheory 18y ago
    Raganwald, i agree with your identification of this problem. But the anti-Ruby trolling is getting out of control :( (and i don't blame you for that). There are a couple different suggestions people have discussed, but some of them, like selector namespacing, have been languishing in discussion land for years (Matz has been talking about it for a while apparently). This still doesn't solve the case where you have two different plugins or gems that you'd like to use, that require different versions of the same gem. Ruby is open enough to give you enough rope to hang yourself w/ in this case. The alternative is what... just not doing package versioning? That seems like a step backwards too.
    - raganwald 18y ago
      > The alternative is what... just not doing package versioning? That seems like a step backwards too. Imagine that you have lexical scope for changes to global constants. Like Perl's local keyword or Lisp's let. So you can redefine Array and the new definition is only valid within the lexical scope of a block. Code that the block calls does NOT get the new definition, so your code can have one version of Array#sum, my code can have another, and we can freely call each other or call code that doesn't expect Array to have a #sum method. Now thinking about that solution to the meta-programming collision problem, the solution to the gem version problem is also plain: gems can be scoped too, and if I use version 1 of a gem in a block and you use version 2 in a block, only the code within our blocks see the effects of the gems they include. So yes, packages have versions, but the same mechanism that applies lexical scope to meta-programming mediates package version conflicts.