Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Ruby Before Perl? Nah.

by starX (Chaplain)
on Jun 03, 2008 at 20:10 UTC ( #689996=perlmeditation: print w/ replies, xml ) Need Help??

A recent project I've been working on has brought me into more intimate contact with the Ruby programming language than I have had before, and as I take a moment to return to maintaining some Perl apps I've written, I thought I might share some of the the thoughts that came into the head of this Perl programmer as he delved into Ruby for the first real time.

I don't mean this to be a exhaustive list of differences, a detailed technical comparison, or an introduction of Ruby for Perl programmers. Just a gathering of thoughts that I feel the need to share.

What a Dump!

I see it time and again: people dismiss Perl as ugly looking and hard to maintain. As we all know this is because Perl lets you do all sorts of elegant things; whether or not you should is another matter, and Perl Best Practices stands as a very nice guidebook of do's and don'ts. I know my code certainly improved after reading through it.

Ruby seems to escape this criticism, and yet it can be every bit as ugly. A lack of curly braces around definitions takes some getting used to, and it makes a poorly indented application hard to read at a glance.

Another big departure was in the lack of line separators (;), or perhaps I should instead say that they're optional. While I can see the argument that this forces readability via-a-vie a one line, one statement structure, the fact that line separators can be used removes this benefit.

Lesson: You can make Ruby every bit as messy as Perl if you want to.

OOPs and Infrastructure

Here I see a very clear benefit to Ruby. No doubt this speaks more to my abilities with the language, but I learned Object Oriented programming with Java, and moving into that particular area in Perl was cumbersome.

Ruby, on the other hand, is OO from the ground up, making it more friendly to the Java trained OO programmer. Or at least to this one. Ruby takes it a step further though, and does away with primitive types, and the result is some very clever infrastructure. An array variable, for example, is an instance of the Array object, and contains useful methods for working with the array; iterators, for example. Hashes work similarly.

From this Perl programmer's perspective, it takes some getting used to. Instinctively one wants to write

foreach my $member @array { ... }
rather than
array.each { ... }
Then again, that's a habit that one learns to change. Which brings me to the next item.

The Variable Appearance of Variables

Perl programmers have got used to being able to tell what they're looking at at a glance. $scalar, @array, %hash are all great ways of being able to figure out what sort of data you're working with at the moment. No looking back to see if c was declared as an int, a char, or a float. Easier to keep track of what you and other people are doing.

Ruby doesn't use this convention, and boy did I miss it. The @ character makes an appearance to signify a class an instance variable, and two of them together (@@) make a class variable, but that's it. The fact that hashes and arrays are both indexed using square brackets ([]) contributes to the confusion. It's good that these elements are present, but it's a potential pitfall, and again, it takes some getting used to.

Also, it helps you appreciate one of the ways that Perl is more readable than its counterpart.

Testing and Documentation.

Perl and Ruby both provide excellent testing and documentation facilities. Where Perl has POD, Ruby has RDoc. Where Perl has Test::More, Ruby has test/unit. Both are invaluable tools if used properly, and it's worth taking the time to get to know how to used them.

Community Support

There is no CRAN, and there are no Ruby Monks. That's not to say that Ruby doesn't have it's own module system (rubygems.org), but it's nowhere near as robust as CPAN. Likewise, I managed to find some folks to answer questions I had in irc, but Perl monks it is not.

This is, I think, a reflection of the relative maturity of Perl to Ruby. With a decades long an eight year head-start, Perl has grown a community of developers; many of whom have been willing and eager to post the best of their libraries for others to use. It's those same developers that can lend their time and expertise to those of us who might not know any better. Ruby has neither of these things because it hasn't been around long enough. Given another decade, that may change.

Conclusions

Ruby is an excellent language, and I'm interested/eager to learn more about it. With a variety of Ruby related modules on CPAN, interoperability between the two languages doesn't appear to be out of the question. It seems to me that Ruby will make a better choice for OOP when it's called for, and can be an excellent way of rapid prototyping class hierarchies before developing them in another OO language.

That said, I've always believed that the strength of any organization is in its people. Perl provides the model of a development community that other languages strive for, and as a result, when I'm presented with a task that seems unusual, awkward, or that requires fitting the square peg in the triangular hole, Perl will continue to be the natural choice.

Further Reading

  1. http://use.perl.org/~jmcada/journal/32457
  2. Thomas, Dave. Programming Ruby, The Pragmatic Programmers' Guide. Pragmatic Programmers, LLC. Raleigh, 2005.
  3. Introduction to Ruby for Perl Programmers
Update: Thanks to the monks who have corrected some of my errors. I have made changes in the above text that incorporate their edits, while leaving the original incorrect data present and struck through.

Comment on Ruby Before Perl? Nah.
Select or Download Code
Re: Ruby Before Perl? Nah.
by kyle (Abbot) on Jun 03, 2008 at 20:26 UTC

    Have you, by chance, put this up at a Ruby-focused site? I'd be interested to read comments on it from entrenched Ruby folks.

    In any case, thanks for sharing. I haven't ventured outside Perl much since PHP, but if I were going to explore for the sake of exploring, I might sally forth into Ruby territory. I appreciate your scouting.

    On the topic of variable appearance: I've been thinking for a while that Perl's references obscure the old useful sigils. That's just my hobby horse, however.

      Have you, by chance, put this up at a Ruby-focused site? I'd be interested to read comments on it from entrenched Ruby folks.

      I would be too... my (brief) encounters with the Ruby community so far have only turned up rampant fanboi-ism. Actually, it's one of the things that's put me off pursuing Ruby further. I'm sure it's just a case of bad luck, altho I do suspect that the average Rubyite is a bit more defensive than the averager Perler (I think Perl coders are just used to abuse nowadays). Would be interesting to compare the quality of responses to a post on a Ruby site to those on this site (which are all excellent so far).

      It won't trigger any interest in Perl among Rubist. You won't be able to trigger any interest of Hillary among Obama supporters. See what's going on? Generation differences.

        Triggering interest would be nice, but mostly I was asking out of my own interest, already triggered. Much like other subjects (including politics), I find it interesting to read the perspectives of those who hold opinions different from my own. How do the Rubists "hear" the opinions of the Perl folks who've visited? How do they view those same features themselves? With enough discussion, sometimes it's even possible to trace opinions back to the core values that support them. That is interesting—more interesting than Ruby is to me, and probably more interesting than Perl is to a Rubist.

Re: Ruby Before Perl? Nah.
by starbolin (Hermit) on Jun 03, 2008 at 21:08 UTC

    Thanks for a well written and balanced treatment. ++

    Question: Perl OO being blessed references gives preference to creating HAS-A relationships whereas Ruby's 'everything is an object' should gives preference to creating IS-A relationships. Did you find this to be true? In other words, theory says that Inheritance should be cleaner in Ruby while Aggregation should be cleaner in Perl. For myself, I don't have any experience with Ruby so I would appreciate any insight you can give.


    s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}
      Short answer: yes.

      Slightly more long winded answer: Inheritance in Ruby is a perfectly natural thing to do from the Java OOP's perspective. The syntax is different, of course, but the fundamentals of non-multiple inheritance remain the same. There are Java-like interfaces available to fake multiple inheritance, but the project I was working on wasn't complicated enough to need them.

      After reading your post, I think I understand *why* I've found OO in Perl to be as cumbersome as I have; I have a tendency to think about objects in ISA terms. For what it's worth, the initial specs for the project were looking at modeling from a HASA perspective (a top down approach). This quickly proved cumbersome, and it made more sense to look at it from the ISA perspective, which is a lot more bottom up.

      I can't say if this speaks more to my personality or my programming ability than it does to the nature of the language though. I'm sure modeling the HASA relationships would have been easier to do if I had more of a background in UML or Perl OO rather than Java, but the inheritance features of Ruby certainly make ISA modeling straightforward and easy to do.

      Hope I managed to give you an intelligent answer somewhere in there :)

Re: Ruby Before Perl? Nah.
by almut (Canon) on Jun 03, 2008 at 21:15 UTC
    There is no CRAN

    Actually, there is ... but it's something else :)

Re: Ruby Before Perl? Nah.
by Fletch (Chancellor) on Jun 03, 2008 at 21:57 UTC

    As to the lack of sigils and arrays and hashes both being indexed with square brackets, that gets more into the Ruby tendency to favour interface polymorphism (or as it's often referred to, "duck typing"). So long as what you're calling the [] method on responds to that method, everything is hunky-dory and it allows for some nice flexibility. I think the example given in one of the books was code which was using a string IO instance with << to build up something for output and the temporary objects were killing performance; they swapped to passing in an array which also groks << (and then called join afterwards once) and the app went from terrible multiuser performance back to acceptable (or something along those lines).

    Not that this approach doesn't also have issues (e.g. you call method zorch expecting the object to do foo, but instead it does bar and wipes your hard drive . . .), but there is a rationale behind it.

    And also there is a more traditional looking for loop, but it's really (mostly) syntactic sugar for calling each:

    for var in iteratable puts "Frobnicated: #{var.frobnicate}" end ## is pretty much just the same as this . . . iteratable.each { |var| puts "Frobnicated: #{var.frobnicate}" }

    But really that's like persisting to use C-style loops in Perl . . . :)

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

      Not that this approach doesn't also have issues (e.g. you call method zorch expecting the object to do foo, but instead it does bar and wipes your hard drive . . .), but there is a rationale behind it.

      I'm used to seeing posts like this explaining Ruby's object system when it's being contrasted to C++ or Java, but is this really noticably different from Perl's OO system? How does foo.zorch in Ruby differ from $foo->zorch in Perl? If it looks like duck typing and quacks like duck typing... ;)

      Indeed, I believe we could use Perl's OO support and operator overloading to do exactly the same things as Ruby does, right down to accessing arrays and hashes with the same kinds of bracket. The reason we don't is twofold:

      • Abstraction on the "everything is an object" scale is inefficient. Perl hackers prefer to save it for where it makes their code easier to read and write, instead of religiously abstracting everything just because we can.
      • Code is more maintainable when different things look different. Arrays and hashes have very different semantics.

        Good points.

        The wikipedia article I referenced says "Perl's runtime method call mechanism naturally supports duck typing.". The thing is I think people writing Perl don't tend to think "the duck typing way" (if one might posit such a thing) to the extreme that Ruby encourages it. Not to mention that if you really want to in Ruby you can individually override / extend a single instance at runtime to implement an interface if need be (of course with Moose and friends you can do similar in Perl, so . . . ).

        And yes, there's overhead to the smalltalkesque everything's-an-object everything's-done-sending-messages model. Ruby's still got speed issues, but it's still got lots of elegant points. I'll often whip first passes of CSV munging together using Ruport because Ruport::Data::Table allows some really succinct code; if speed's an issue then it's time to drop back to Text::CSV_XS or Tie::Handle::CSV.

        The cake is a lie.
        The cake is a lie.
        The cake is a lie.

Re: Ruby Before Perl? Nah.
by MistaMuShu (Beadle) on Jun 03, 2008 at 23:43 UTC

    Just a small typo in "Appearance of Variables". In Ruby, @ signifies an instance variable and @@ signifies a class variable. Switching between Perl and Ruby often makes me mistype '@' for array :)

    I definitely agree with the community support. PerlMonks is by far the most helpful and best moderated site I've seen. I feel that the popularity of Rails has attracted fanboys and flamers who are detrimental to Ruby's image. I try to stay out of the "I'm better than you" arguments.

    What impresses me most is Ruby's metaprogramming support. I don't know that many languages, but Ruby is the first one that I've seen it so well integrated into the syntax and language. It's not cumbersome to use, and is widely used in Rails and other libraries.

Re: Ruby Before Perl? Nah.
by Jenda (Abbot) on Jun 04, 2008 at 00:17 UTC

    I don't mind that you don't have different sigils for scalars, arrays and hashes (the number of characters is rather restricted compared to the number of different types you might want to distinguish like that), what I do mind is that there are no sigils at all which combined with the fact that you CAN'T declare variables is rather ... nice.

    In Perl I can say HEY DUDE THIS IS A NEW VARIABLE no matter what variables exist elsewhere. In Ruby you can't and the usual response of faithful Rubyists is that it doesn't matter because all methods should be at most up to five lines anyway. Which 1. is not always possible and 2. forces you to be very inventive when nameing them. Plus due to the missing sigil it's not just variables that can clash. So you may define something several months later several pages away and voila, your local variable is no longer local variable. If you are lucky it's not a variable at all and you use it in some way that'll cause a syntax error. Oh, I forgot, you are supposed to have tests for everything so nothing bad can happen anyway right? I don't need the seatbelts, I'm a good driver, right?

Re: Ruby Before Perl? Nah.
by educated_foo (Vicar) on Jun 04, 2008 at 02:58 UTC
    There is no CRAN, and there are no Ruby Monks. That's not to say that Ruby doesn't have it's own module system (rubygems.org), but it's nowhere near as robust as CPAN.
    The real turd here is that gems isn't just a package repository, but is required at runtime in your script, and imposes significant overhead. It amazes me that Ruby has adopted it.
Re: Ruby Before Perl? Nah.
by stvn (Monsignor) on Jun 04, 2008 at 07:07 UTC
    OOPs and Infrastructure

    Here I see a very clear benefit to Ruby. No doubt this speaks more to my abilities with the language, but I learned Object Oriented programming with Java, and moving into that particular area in Perl was cumbersome.

    You might want to take a look at Moose it helps take the pain out of Perl OO.

    -stvn

      I see that you have a number of Cookbook examples in the docs. However, I tend to prefer a tutorial. I don't see any Moose::Tutorial (hm - is that the name that would be used for it?). Are there any tutorials you recommend?

        Take a look at http://www.iinteractive.com/moose/ in the "articles" section are two nice Linux Mag articles that merlyn wrote, and an interesting comparison of Moose to Ruby by Barry Walsh. You might also want to look in the "presentation" section as well, some of the talks are kind of tutorial-ish. And if you are going to YAPC::NA this year in Chicago I will be giving a tutorial on Moose there this year. And lastly, if you are on IRC, feel free to stop by #moose on irc.perl.org the community there is pretty helpful.

        -stvn
Re: Ruby Before Perl? Nah.
by rovf (Priest) on Jun 04, 2008 at 08:09 UTC

    Having done projects in Ruby and in Perl as well, maybe I can contribute a few personal impressions:

    In both languages one can see the intent of the authors to make it practical to use. Larry and Matz both seem to prefer writing short, concise code over long winded ones (as you maybe would end up when using Java).

    In both languages you find obscure and dark corners, but the ugly parts of Ruby are very different from the ugly parts of Perl. This comes to no surprise, as Matz, when inventing Ruby, had a deep Perl background and tried specifically to avoid the weaknesses of Perl.

    Also, as always, what is ugly for me might be great for others. I dislike the Ruby feature to make it easy to define aliases for functions (where you can call the very same function by a variety of names), but others find it handy.

    When it comes to writing programs (as opposed to reading them) I found both Perl and Ruby easy to learn. You come quickly to a point where you can produce useful code. In this respect, I find Ruby a bit easier, but this too is just my personal impression.

    And, if you came (like me) from Perl to Ruby, you will feel familiar with many standard modules (Net::FTP etc.), because their design is patterned after their Perl equivalent.

    I enjoy working with various languages. When I do shell scripting, I like to use both bash and zsh. When I do serious programming, I like to do both Perl and Ruby. I would be interested in doing somethin in Python, or Haskell, too. If you are like me in this respect, it might be worth giving Ruby a try...

    -- 
    Ronald Fischer <ynnor@mm.st>
Re: Ruby Before Perl? Nah.
by bilfurd (Hermit) on Jun 04, 2008 at 08:32 UTC
    Ruby does take some getting used to. "Rails" is pretty slick, though the differences between v1.x and v2.x are enough to drive you mad. The "objectiness" of the language has a certain charm. A different feel to the language, if that makes any sense.

    The lack of sigils and line terminators does bug me, though I can get into the groove after a while.

    I'm just glad they Mats didn't follow Guido with the whitespace...

    When all is said and done, Ruby does not have a Perl Monks. Until there is an established, non-fanboy "Ruby Monks", it will be a lot easier to get things done with Perl.

Re: Ruby Before Perl? Nah.
by samizdat (Vicar) on Jun 04, 2008 at 13:10 UTC
    I'm in the midst of a RoR project. In a lot of ways, "the Ruby Way" is a help, in that I can just follow one of many linear project books to its conclusion and out pops a completed website. Ruby and Ruby on Rails are an amazing set of constructs.

    What I'm seeing as I go, though, is that the book writers are leading me through an amazing jungle of different syntax patterns. (And no, I haven't tackled Rails 2 yet) It makes me appreciate how much web I do know with ten years of background, because at least I have a grounding in JavaScript, HTML, make, CGI, and a whole bunch more so that I can at least parse the boundaries of the different layers in the code.

    The OP points to optional bits of syntax like curly brackets around hashes, and I agree that takes a lot of getting used to. It does make the code cleaner to look at, and idioms do tend to become very familiar quickly since Rails only uses a common subset of Ruby, relying heavily on symbol-referenced hashes.

    I think the online docs (api.rubyonrails.org, for instance) are very good although their search capabilities could be dramatically improved. I do agree that there's no PerlMonks-equivalent that I've found although there are a lot of websites out there that are built on a social network framework. Ruby is very much a new kid on the block still, and it takes time to attract the kind of multitalented person who will nurture a PerlMonks until it takes off.

    Now the tough question: Perl or Ruby? I still use Perl one-liners a lot. For scripting and one-pagers, I have not made the transition to Ruby. What I do like about Rails is that it's amazingly powerful and complete for web system-building. I'm sure that Mason and other Perl-based frameworks can do a lot, too, but Rails (even with a learning curve and constantly improving capability set) lets me do a huge amount with a very small amount of code, albeit in four different syntax structures. If it weren't for Rails and something else I'll get to in a moment, I'd be fairly comfortable staying with just Perl although I agree with the comment that Ruby OO and collection classes are far better. Perl is everywhere, more people can read and debug it, and it works well for a lot of different tasks.

    The one over-the-top is the books I mentioned before. Since Rails does so much for you, it's possible to build a complete shopping site or social network within the few hundred pages of a book -- including detailed test frameworks on unit, functional, and integrative levels. Wow. Ruby also has lots of learn-the-language books, but this new thrust of build-something-from-the-ground-up books is one arena where Perl (Mason, TT, Embperl) books have not kept pace. Even the O'Reilly books on Mason et al fall far short; they're more cookbooks than guided projects. Perl started this trend in the early days with CGI, but it has not kept pace due to the fragmenting of the landscape.

    I think community will come with maturity in Ruby. Certainly there are local user's groups with active memberships. I haven't seen the fanatics yet, myself, but then, I would diffidently suggest that those types are a fixture of the open source community and show up in every project at one stage or another, as anybody who's ever been whacked over the head with a stuffed penguin will agree.

    I'm not one who has a right to criticize. Though I've contributed in a small way to The FreeBSD Project over the years, I'm much more a user of open source than a developer. Those of you who've followed my growth here know that I'm a strong believer in getting the job done whatever the toolset. Just as there's room at PerlMonks for Corn Flakes and Beer alongside bananas and grape juice, so, too, is there room in the world for both Ruby and Perl.

    Don Wilde
    "There's more than one level to any answer."
Re: Ruby Before Perl? Nah.
by Your Mother (Canon) on Jun 04, 2008 at 18:32 UTC
    This is, I think, a reflection of the relative maturity of Perl to Ruby. With a decades long head-start, Perl...

    To clarify, Perl was released 1987, Ruby 1995. 8 years does not decades, or even decade, make. To a large degree, Perl's maturity is an outgrowth of its incredibly broad usefulness. It fits into so many problem spaces that its user base brought a tacit maturity almost from the beginning.

      3 months in human years = 1 year in computer years?

      Or alternatively, by decades I meant cumulative hours of development time?

      No, just had the date wrong. Thank you for the correction :)

Re: Ruby Before Perl? Nah.
by bart (Canon) on Jun 09, 2008 at 20:18 UTC
    Ruby, Perl, Python...

    Those are all the usual suspects.

    And despite their differences, I still feel that they're actually more alike than different.

    Are there any other languages, that are usable in the same way as Perl/Python/Ruby, that you consider interesting as alternatives, but that are not (constantly) in the spotlight, and that may be worth looking into?

      I've been meaning to take a look at Lua for a while now. It looks syntactically similar to Ruby, and is designed to be primarily an extension language for C/C++; but that's from a cursory examination of the manual. It's worth mentioning that there is also a Java interface available, and the same folks who produced that have developed a web application framework to support Lua. If it really is as fast as the hype indicates, maybe it's worth looking into. Otherwise, it's probably just another mouse trap.
        I looked at lua a few months ago, and this is what I found:
        • It's a neat, small language
        • Variables are global by default (like in perl), but no use strict
        • The "A hash and an array are the same thing" concept really needs some time to adapt
        • Simple things aren't always easy, hard things not always possible

        Especially the second and the last point of that list convinced me not to adapt it as a general purpose programming language.

        However for the area it was designed for (being embedded in other applications) it sure is very cool and useful.

Re: Ruby Before Perl? Nah.
by parv (Priest) on Jun 09, 2008 at 21:58 UTC
    After reading the title "pearls before swine" jumped immediately in my mind. (Mind that I am not implying any relation(s) among Ruby|Perl and pearls|swine. I should rent an asbestos suit in any case.)
Re: Ruby Before Perl? Nah.
by spurperl (Priest) on Jun 13, 2008 at 04:46 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://689996]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (6)
As of 2014-10-25 06:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (142 votes), past polls