

We need the eggs - raganwald
http://github.com/raganwald/homoiconic/blob/master/2009-04-17/eggs.md#readme

======
tdavis
I'm actually starting to feel sorry for Ruby developers. It seems like any
time you install something it can anonymously and unapologetically squash any
other thing, whether it's a built-in method, an existing module, or what the
meaning of "is" is. Honestly, I'd probably be too afraid to ever install a
gem.

~~~
ionfish
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
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
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

~~~
jerf
"Nor is this a problem that scales with community size." - The more people you
have writing libraries, the more monkeypatches are made in a library, the more
likely it is that the monkeypatches will collide. That's so obvious I don't
even know how to argue for it.

"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."

I do, because other languages manage to provide features and libraries without
causing this problem. A problem that is unique to the monkeypatching languages
(also Javascript) can be laid at the feet of the design decision to permit it
and the community decision to roll in it.

If the community is indeed walking away from monkeypatching.... that doesn't
prove I'm wrong, it proves I am and was right about the dangers involved. I
don't feel inclined to give the community much credit for coming around to the
realization that unfettered monkeypatching is a bad idea two years later than
I did.

If you like monkeypatching, you should be listening to Raganwald. He's looking
for a way to reap the benefits without paying the price, and I think such a
thing could be constructed.

Version control is a separate problem indeed. It should be pointed out that I
was responding not directly to the original topic, but the posts that are the
parent in this chain. This is perfectly valid.

Oh, and stuff it with the trolling accusation. I'm not looking for flaming
responses, I'm hoping to safe someone from stepping into the monkeypatching
tarpit that at least historically the Ruby community has advocated so hard for
people to leap into. Again, if the community is walking away from that tarpit
too, are they "trolling" when they do that? Trolling means something, and it
isn't "having strong opinions with reasons given".

~~~
aaronblohowiak
This is not a monkeypatching problem, per se. It is a problem of scope-
independent class definition. There are languages wherin you can monkeypatch
the class definition (or the definition of a single instantiation of a class)
wherin those patches only are in effect in certain contexts.. so you have a
scope to your monkeypatching. I think that this would allow for Interesting
Things, while being "safe".

~~~
catch23
Sometimes monkey patching is good actually. I use Soap4r all the time, and I
preferred the debug xml to appear in the console rather than created as a
separate file, it was really easy to make a monkey patch that fixed this,
without modifying the actual distribution... that way other projects wouldn't
be affected.

Another time, there was a small bug in Hpricot, rather than fix it directly in
source, I patched it in my code, and removed the patch when the fix was in the
production stream.

At least it's nice to have that option available...

------
mr_justin
Been bit by that more than a few times, that's why I always freeze rails now.
It is the only way. Things should be simpler and more reliable.

ps. I love that you're running your blog through github. Very ingenious.

------
smhinsey
if i am not mistaken, you can get into similar trouble in javascript with
object.prototype. it's interesting that you don't hear much about that, but
maybe people just don't expect as much from it.

------
aston
Mere coincidence that the Python's gem-like packages are called eggs?

~~~
andreyf
I wondered that, also: I didn't think Python's eggs solved this problem... do
they?

~~~
nuclear_eclipse
No, eggs are just an unofficial, "convenient" method for distributing Python
modules.

However, AFAIK, Python itself "solves" this problem simply by giving errors
whenever you try to import a different version/instance of a module, but I
could be wrong.

~~~
andreyf
If you're talking about the native Python modules, I'm pretty sure Python
simply ignores repeated imports (and there is no version number in most module
names).

