<p><pre><code> For example, rubygems (probably my least favorite ruby
software of all time) basically require that you always try
to load them, because their design stupidly requires that
you know whether a given piece of software is installed via
rubygems or some other mechanism.
</code></pre>
Nearly all libraries nowadays are installed via RubyGems. For most of its life, RubyGems has been the "de facto" way to install libraries, but not the 100% officially-sanctioned route. As such, it's necessary to require RubyGems in first, then the libraries you want to load. This takes all of 10 seconds to learn.<p>The poster has missed the point somewhat when it comes to the use of vendor. "vendor" is used in situations where you have to remain fixed to a certain version of a certain library AND you're not 100% confident that your deployment environment will have that version of the library installed. In this way, it's a better solution than just praying the remote server has a certain library installed or ending up with a script that fails on the library version assertion, as with Perl. Overusing vendor is, however, a lazy way of doing things, and the sloppy programmers this guy has spoken to do not represent the community as a whole.<p>From the comments:<p><pre><code> To me, this is one of the really big things that defines
Perl as a mature language community: Perl people don't do
this nonsense. There's no "vendor," and you're looked at
like you're out of your mind if you distribute copies of
other people's modules with yours instead of declaring
versioned dependencies in your Makefile.PL.
</code></pre>
(Good) Ruby people don't do this nonsense either. RubyGems supports you specifying the gem name and required version (or required minimum version) in a similar, or better, way than Perl.<p>This is an over-rated post telling us about a problem that only exists in the ignorant. It's cut from the same cloth as all the misinformed "Twitter's Dropping Rails!" posts and I'd expect better from the voters on HN.
Swings and roundabouts.<p>Personally, I use Ruby for stand-alone apps more than for Rails. I do command line tools and Mac apps using RubyCocoa. I can't guarantee that my product functions as planned if I can't control what code it uses.<p>For libs which belong to the core OS, I am comfortable with using shared libs. These libs are very well documented, and the interfaces don't move. Any changes made by the OS vendor are generally for fixing bugs.<p>For everything else, I have no guarantee, and hence little trust, that the developer isn't going to change their lib in a way that breaks my code. In such a case, I much prefer to take control over that lib by bringing it into my own project as a static lib. I give my app it's own auto-updating feature, and I take responsibility for keeping the static libs up to date. That takes care of potential security issues.
Not so much a distribution problem, but a platform problem - I cannot get Ruby to compile on an Itanium HP-UX box - even the HPUX ports site says it won't work :-(<p>If anyone has got it to work please let me know!