in reply to Honest question about Perl, Python and Ruby

I've been programming in Ruby for a couple years now (after having programmed in Perl for over 15 years), so maybe I'm qualified to give some anecdotal testimony (which will basically confirm what fullermd said above).

It seems like Ruby is a sort of middle-ground between Perl and Python: it actually borrows some idioms directly from Perl (including the command-line options that allow for really nice one-liners), and like Perl, it has a fairly strong (and seemingly popular) presence for web developers. But like Python, it's firmly and fundamentally object oriented.

If you happen to deal a lot with Unicode (non-ASCII) text, you'll like Ruby v2, because utf8 character handling is there "by default" - just open a file and read or write text in any language without further ado. (Opening a non-text file in binary mode is no harder here than in any other language.) Once you get your head around using (and chaining) method calls on objects, the code can become relatively compact compared to Perl.

Alas, it doesn't necessarily make the code any more easy to read or write, if you haven't memorized the relevant facts about all the various objects, or grasped the finer details of syntax and punctuation. (I'm tempted to refer to some patterns as "syntactic gristle" as opposed to "syntactic sugar.") The core documentation for Ruby is okay (not as clear or complete as Perl's, but not bad). Third-party module documentation typically stinks, if there's documentation at all. (A lot of Ruby module developers seem to think that "look at the source code" should be all the documentation anyone will ever need.)

Yes, there is a place where you can search for freely available Ruby modules that do useful things, but it doesn't hold a candle to CPAN in terms of breadth and ease of search, and some of the "nearly core" modules (covering things like database connections and XML parsing) have documentation that seems unduly maze-like to the newcomer. And then there's the occasional clunker, like the "zip file" module with a really bad memory leak. But maybe it's just a matter of time - Perl has been around somewhat longer. (Then again, Perl has had really good documentation since the early days, and subsequent developers have been following a well-established good example. Ruby's start-up and subsequent developers, not so much.)

Apart from having a user community that appears to be better at sharing, documenting and peer-reviewing code, Perl has a notable advantage for doing arbitrary data structures (HoAoH in Ruby is not so easy). Of course, it may just be that Perl seems better to me because after all these years, I've gotten really used to it.

Lately, when I have to do quick, one-off things on the command line, I find that some tasks are easier in Ruby, and other things are easier in Perl, and I choose accordingly.

(updated to fix a typo)

  • Comment on Re: Honest question about Perl, Python and Ruby

Replies are listed 'Best First'.
Re^2: Honest question about Perl, Python and Ruby (autovivification)
by eyepopslikeamosquito (Archbishop) on Feb 07, 2015 at 07:34 UTC

    Perl has a notable advantage for doing arbitrary data structures

    I wonder if this advantage is due to autovivification or are there other reasons? AFAIK, autovivification is unique to Perl. A simple illustration of autovivification in Perl vs Ruby (taken from this old golf node) is: 

    $z[ 0][ 8] = 'o';
$z[ 1][11] = 'o';
$z[ 3][14] = 'o';
$z[ 5][15] = 'o';
$z[ 7][14] = 'o';
$z[ 9][11] = 'o';
$z[10][ 8] = 'o';
$z[ 9][ 4] = 'o';
$z[ 7][ 1] = 'o';
$z[ 5][ 0] = 'o';
$z[ 3][ 1] = 'o';
$z[ 1][ 4] = 'o';
print"@$_\n"for@z;

    [download]

    To emulate the Perl test program above in Ruby, you might try: 

    z=[]
(z[ 0]||=[])[ 8] = 'o'
(z[ 1]||=[])[11] = 'o'
(z[ 3]||=[])[14] = 'o'
(z[ 5]||=[])[15] = 'o'
(z[ 7]||=[])[14] = 'o'
(z[ 9]||=[])[11] = 'o'
(z[10]||=[])[ 8] = 'o'
(z[ 9]||=[])[ 4] = 'o'
(z[ 7]||=[])[ 1] = 'o'
(z[ 5]||=[])[ 0] = 'o'
(z[ 3]||=[])[ 1] = 'o'
(z[ 1]||=[])[ 4] = 'o'
puts z.map{|i|(i||[]).join" "}

    [download]
    Note that, because Ruby does not autovivify, you must manually create the empty lists -- using the || operator in the test program above. Note further that 0 and "" evaluate to true in Ruby, so the Ruby || operator is closer to Perl's // "defined or" operator than its || "or" operator.

    Update: As noted in brian_katzung's necropost reply below, you can autovivify nowadays in Ruby using his XKeys Gem. Some links:

[reply]
[d/l]
[select]

      You can autovivify in Ruby with my XKeys Gem.

      require 'xkeys'
z = [].extend XKeys::Auto
z[0, 8] = z[1, 11] = ... = z[1, 4] = 'o'

      [download]

      And

      node_info = {}.extend XKeys::Auto
node_info['list', :[], 'name'] = 'new node' # :[] means next index
#  {"list"=>[{"name"=>"new node"}]}

      [download]
[reply]
[d/l]
[select]
Re^2: Honest question about Perl, Python and Ruby
by Anonymous Monk on Feb 07, 2015 at 06:36 UTC
    If you happen to deal a lot with Unicode (non-ASCII) text, you'll like Ruby v2
    Is that so? The last time I looked at Ruby, even the simplest things (like "Я".downcase()) didn't work. Not to mention full casefolding, properties, normalization, collation... there were some slow, 'pure Ruby' libraries... it was pretty bad. Is it improved now? I kind of got an impression that Japanese dislike Unicode because it makes their alphabet look like Chinese or something (but maybe it's a false impression that says more about me then about the Japanese).
[reply]
      Thanks for pointing that out. I stand corrected. (To their credit, this is one case where the ruby docs are clear: "... Note: case replacement is effective only in ASCII region.") Oh well, room for improvement there.

      Update: FWIW, a ruby user can do "gem install unicode_utils", and then do things like: 

      #!/usr/bin/env ruby

require 'unicode_utils'

puts UnicodeUtils.downcase("Я")  # aka "\u042F", "CYRILLIC CAPIT
+AL LETTER YA"

      [download]
      It's clunky, but it works. (I wish the "code" tags here would allow a letter like "Я" to appear as such.)
[reply]
[d/l]
Re^2: Honest question about Perl, Python and Ruby
by bitingduck (Deacon) on Feb 10, 2015 at 05:34 UTC

    I do about equal amounts of Perl and Ruby (neither as the core of what I do to eat) and generally agree with what graff has posted above. I stay away from Python because of the indentation thing, but I suspect I'm going to have to deal with it more soon. I probably wouldn't do a lot of Ruby if it weren't for Rails (and the various good and bad that comes with it)-- it's an easy way to get a site up fast, and Spree is easy to set up a store with and easy to modify, particularly if you're only doing it infrequently but want to do some non-standard web store things. If I need a quick hack for something, I go to Perl first (or C if I need a low level language).

    As far as CPAN vs various Ruby gems, there's no comparison. Not only does CPAN have incredible depth and ease of finding useful modules, but they play very well together. I can't remember the time I tried to do something and had a conflict between module versions in Perl, but it seems like gem dependency version conflicts show up any time you try to do anything.

    The prevalence of conflicts in Ruby gems is also a symptom of another major difference- Perl (at least 5.X) is a much more stable language as far as things like syntax and structure. The Ruby community (or parts of it) seem to fall prey to the "ooh, this is a cuter syntax, lets deprecate the old one!" a little too easily, and when you get forced into upgrading your Ruby you tend to have to go fix up a bunch of things that have been dropped since you last touched the code. It might be good job security for some people, but I mostly code because I need to get stuff done and I don't want to have to go back and rework stable code because someone decided to change the hash syntax.

[reply]

In Section Seekers of Perl Wisdom