Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

One more perl programmer's take on Ruby (discussion)

by deprecated (Priest)
on Nov 18, 2001 at 02:04 UTC ( #126047=perlmeditation: print w/ replies, xml ) Need Help??

I've been talking to a lot of people about our trade, as programmers lately. Well, let me back up. Some people here arent trade-programmers, but program for fun. So maybe some of you guys haven't gotten the ruby "buzz" thats going around.

At work, we seem to have two different kinds of programmers. Programmers who do what they do because they went to school, learned it, and they make a living doing it -- and the other kind. The programmer who seems to code because he or she actually likes to do it. I'd even call these people 'code junkies' some times.

At any rate, the more chatty of the two programmer stereotypes above is the code junkie. These are the kinds of people who will code in INTERCAL for the express purpose of a challenge or having fun coding. The cool thing is most of these people are as various and diverse as, well, people in general. So while I am a professional perl programmer, I may have a closet Forth or Scheme fetish, and my co-worker may think that JavaScript is his crack of choice.

So, like memes, sometimes programming languages go around and embed themselves in new communities. I think that perl is such a language. It caught unix admins, C programmers, and shell programmers (and my apologies, but I'm going to include awk programmers in that bunch) sort of by surprise. Lo, there was a new language, and it was pretty cool. It had new syntax and new features and made the hard tasks less hard and the impossible tasks possible (Napster clients in awk, anyone?).

Lately, I've been hearing a lot about Ruby. My friend Dan referred to it as "Perl's younger, prettier sister." A prospective employer looked at a code sample of mine (perl) and asked me if I had looked at ruby; not because it was a skill for the job, but when somebody uses perl like I do, they might be interested in Ruby.

I had heard about it, but had no idea what it was about, and the very few samples I had seen reminded me of Python, which, frankly, makes me sick.

Well, after enough people had told me to check it out, I decided to buy the book. I had just finished my new Tom Robbins Book, and had some time to kill. So I picked up Programming Ruby, The Pragmatic Programmer's Guide.

After about 20-25 pages into the book, I had Ruby pretty much understood. Many of the stuff is totally intuitive for perl programmers.

My impressions of the language are pretty much as Dan expressed it to me: it's a younger, fresher, prettier language. This isnt to say that I dont still love and won't continue programming in it. I've got a lot of time and a lot of effort invested in being a good perl programmer (despite what some of our 'bretheren' may think). Furthermore, perl has a lot more functionality in terms of modules and support. From what I can tell there is no 'rubydoc', there is no 'cran', and there is precious little literature. DBI seems to be mostly ported, including DBD::Pg, without which I could not exist.

The object creation syntax of ruby is pure ecstasy when compared to perl's. I've always been turned off by the syntactic ugliness and hoops I had to jump through to make modules in perl. In Ruby, such things not only are easy and clear, but come naturally.

Where ruby is lacking, in my opinion, is flexibility. One of the things I treasure about perl is TIMTOWTDI. A friend of mine on IRC was bitching that what perl is sorely missing is an 'elsunless'. A cute joke, but indeed, perl seems to be missing very few syntactic niceties. Ruby requires you to code in a more rigid way, and be more verbose about things. However, the things you do in Ruby are more clear and easier to code. I think in many cases, Ruby excels at being all the things Perl strives to be. Perl, however, has just hyperfocused on a few of those facets. This is where Ruby's youth shows. It is a very general language and isnt really good at doing a few specific things, it seems to be pretty good at doing a lot of different things.

Its almost like you can see where Ruby is going, but it hasn't gotten there yet. I suppose that's part of the fun of using it.

I'm not going to post contrasting code samples, as that has already been done here, and it doesnt really do the language justice.

My take on the abovementioned book is it was just not written very well. The ages-old example of the "Song" class is overused and unclear in this book. The authors neglected, very early on, to explain that Object.id returns an "id" of that object. It was never mentioned, and its output was just shown as "normal" with no explanations. I understand there is an HTML version of the book online. Read the first 20-30 pages of it, and then start coding your own Ruby. It's not hard, and you'll pick up more that way since you know Perl already.

Cheers, and happy coding.
brother dep. <!- tilly need not reply. :p ->

--
Laziness, Impatience, Hubris, and Generosity.

Comment on One more perl programmer's take on Ruby (discussion)
(ichimunki) Re: One more perl programmer's take on Ruby (discussion)
by ichimunki (Priest) on Nov 18, 2001 at 04:40 UTC
    What inquiring minds want to know about Ruby in order to compare it to Perl (and really, these things in my mind set Perl apart from a LOT of other potential programming languages): does it work as well on Windows as it does on Linux and many Unix systems? Does it also then have a cross-platform GUI toolkit?

    One of the things that absolutely thrills me about Perl is the fact that with the exception of some fancy process management issues and certain filesystem specific things, a HUGE quantity of code is truly cross-platform-- especially nice when considering the Tk module. I realize that Tk probably hasn't been ported nearly as many places as Perl itself, but it is nice to have most x86 systems being able to pick up a client and work with it. And Linux capable PPC too.

    Not that I'm trying to hammer on Ruby, just curious. Especially since I gather it has a "cleaner" OO model, which could be quite valuable in the realm of GUI scripting (especially if you want to get into compound widgets and stuff).
      {In a blatant attempt to gain XP} I will answer my own questions, having taken a 30 minute peek at Ruby and running a Hello, World! or two.

      1) Ruby works on Windows-- the install is painless and includes Tk (better than ActivePerl, which requires additional work to get Tk). As with all claims to cross-platform functionality, this must be taken with a grain of salt. But I see no reason to consider it a better or worse language than others in this regard.

      2) The Tk module. This is included in the binary installer for Windows-- and the example Hello World from the Tk chapter of the docs worked without a hitch. I assume it is similarly easy to crank this up on Linux.

      3) The OO model looks insanely cool. While getting the basics of OO from Perl (with massive help from merlyn's perlboot), I get the sense that Perl 5.x.x has a rather cobbled together OO system (compared to what OO purists would like from an OO system, that is).
Re: One more perl programmer's take on Ruby (discussion)
by VSarkiss (Monsignor) on Nov 18, 2001 at 04:51 UTC

    Interesting note, deprecated. I'd be very interested to see someone (*cough* TheDamian *cough*) do a comparison of Ruby and the new features in Perl 6. It seems some of the benefits that people list for Ruby are the same as some of those I've heard for Perl 6.

    I have to tell you, though, that "it's a cleaned-up Perl" doesn't sell me on the language at all. In my personal experience, that argument has always been bogus. The most glaring example I know of was when, many moons ago, C++ was called a "cleaned-up" C. Around 1993, I had been writing C for several years (and enjoying it), so I learned C++, to the point where I even got paid for writing a class library or two. A few years later, I took another look and recoiled in horror. C++ had become a byzantine, complicated, hodge-podge that completely missed what to me was the strongest point of C: a simple mental model. When I looked at a C program, I felt like I knew what was going on underneath it all. With C++, I had no idea.

    Perl leaves me with the same feeling: when I look at a piece of code, I can build a simple mental picture of what's happening (Erudil's code being a glaring exception ;-). What I'm wondering now is which of Perl 6 or Ruby is more likely to make me say, "Oh, I see, how obvious."

      I'd be very interested to see someone do a comparison of Ruby and the new features in Perl 6.
      It'll happen, count on it.

      In fact, I foresee a three-way comparison -- with Ruby and Python.

      But we need to get Perl 6 a little more fully mapped out before we can start comparison-selling it. For example, the most meaningful comparisons can't be made at all yet, because we haven't finalized the Perl 6 OO mechanisms.

Re: One more perl programmer's take on Ruby (discussion)
by elusion (Curate) on Nov 18, 2001 at 06:13 UTC
    Fellow Monks,
    I have done some coding in Ruby. I've read the book also. (which is online here) Ruby does have a GUI, it uses Tk. It works well on Windows (That's what I code in), but I've heard it's faster in Unix. I've not written more than 600 lines, but I've really enjoyed doing it. I am one of the "for fun" programmers that brother dep mentions. I will elaborate a little be here about some of the joys I've had.

    When they call Ruby "Perl's younger, prettier sister," they speak the truth. The syntax is a clean and, for the most part, concise. When it's not the most concise, I find that it is because a little bit of sugar has been added instead. I don't think that it is very comparable to Python. I've looked at Python and have decided it is overrated. Ruby, on the other hand, is nice. Here are some of the things I like:

    Regexp: Ruby provides a builtin Regexp (notice different spelling) class. It is just like Perl's, except you would say /pattern/ =~ "string" instead of "string" =~ /pattern/. Ruby also fills all the regex variables ($`, $1, $2, etc.) like Perl.

    Threading: Although I've not done any threading in any langauge, it seems to be the consensus that Ruby makes it surprisingly simple.

    Loops: I really like Ruby's loops. They are one of the occasions where a little bit of typing has been added to make things cleaner. The first example is Perl, the second is Ruby.

    foreach ($i=3;$i<19;$i++) { print $i; } 3.upto(18) do |i| print i end
    Blocks: This is something different about Ruby. You can pass a block of code to a method, and, at a specified point, the method will execute the block with a variable(s) that is passed to it. This is actually how the .each method works for the Array class in Ruby.
    class Numbers def gimme 3.upto(10) { |number| yield(number) } end end Numbers.gimme { |number| puts number }
    This would print 3\n4\n5\n6\n7\n8\n9\n10\n.

    Operator Overloading: This isn't something that is uncommon in OO langauges, but it is lacking, as far as I know, from Perl's. Take this as an example: You're working on image manipulation. This requires you to create a list of lists. We'll assume that we've already made the lists. In Ruby you would have to write a simple 10-15 line class for this example. To access this in Perl, you would write $image[$x][$y]. In Ruby you could make it do this image[x,y]. True, there's not much difference, but with lots of code this can really make things more readable.

    Class and Object variables: Ruby provides a nice clean interface to different types of variables. To have object variables in Perl, you must have a, in my opinion ugly, %self that contains all your info and is then passed to all the methods. In Ruby, this is much cleaner. All object variables are simply prepended with an @. All class variables, which are the same for all objects in that class, are prepended by 2 @'s. All global variables are prepended by a $. This may look confusing at first for a Perl programmer. Whenever I see a variable with an @ in front, I want it to be an array. But you get over that fairly soon.

    Similarity: Besides all these differences, and some more, Ruby is very like Perl. As Deprecated mentioned, many things are very intuitive, or actually the same, to a Perl programmer.

    This doesn't mean that I will be abandoning Perl at all. In fact, coding Ruby has actually made me like Perl more. It is really good to shake things up once in a while. Perl just has something about it though. Maybe this is because it's my first programming language. I don't know, but I'd encourage everyone, especially the "for fun" programmers, to take a look.

    elusion : http://www.elusion.f2s.com

      As someone who has done stuff in both languages, here are some corrections on each topic you brought up.

      Regexp: In Perl you put the string on the left. In Ruby you can put the string on the left and the pattern on the right, or vice versa. Normally I would write it the same in both languages. What is going on is that =~ is a method of both String and Regexp, for no particular reason than to provide a little syntactic sugar.

      Ruby's threading is cooperative inside of the language. You could implement using class Continuation. This does not give you access to OS level threads. You cannot, for instance, use Ruby's threading and blocking system or database calls. So it is there, kind of. But it isn't really useful for anything I would want threads for.

      Loops In Perl you appear to still be using C-style for loops. Use more Perlish foreach loops and you will avoid most off by one errors. For instance your example is better written in Perl as:

      foreach my $i (3..18) { print $i; }
      (And I would write it similarly in Ruby.) However there is something nice about Ruby. You can loop over anything as long as it provides an each method and imports Enumerable. Why should there be a difference between looping over text you are reading from a file, and looping over text in a String? Matz didn't think there should be, and as a result you can loop over lines of text in a string directly with a foreach, and if you use a foreach on a file since it goes through each, you don't have the slurping problem you do in Perl. (The problem comes when you read a large file into memory then swap.)

      Blocks are just syntactic sugar around anonymous subroutines. You can do it in Perl. You just need to write a few sub declarations. But you won't get the core of the language to make widespread use of it without a significant rewrit. So Perl is able to do it, you just don't have the sugar.

      Operator Overloading Perl has this. See overload. However Ruby's overloading model is much more consistent and fine-grained than Perl's. Everything is an object. Redefine the methods you want. (Except for the comparison operator on a string for a sort. Grrr...)

      Class and Object variables This is one place that Ruby shines relative to Perl. Ruby's OO model is much cleaner, and writing classes and methods is so much nicer than in Perl.

      And now for the points you missed, good and bad.

      First the summary. Ruby is Smalltalk's OO model, with a grammar that is meant to look a bit like Perl's, and a class system designed around emulating Perl. Plus a few Lispish goodies thrown in because Matz likes them. As a result you have at your fingertips most of the basic data manipulation conveniences of Perl, but in a much simpler language, with a dynamic type system.

      But there are differences. Ruby is much simpler than Perl, much more consistent, has a lot of familiarity, and has a far cleaner OO model. Ruby's syntax and type system are separate, for instance write a hash access, array access, and call an anonymous function with foo[bar]. Therefore a large amount of Perl's syntax can be thrown out, while maintaining a far finer-grained type system than Perl has. For instance a Float and an Integer are different things in Ruby, and while with Integer arithmetic you will never overflow, with Floats you have the usual constraints. This also means no autovivification. Unlike Perl, Ruby has true garbage collection. This means a cleaner interior, fewer memory leaks, but you don't get deterministic destructors.

      And there are some bad points. First of all Ruby doesn't have CPAN. Secondly Ruby doesn't have any equivalent of strict.pm, and I definitely missed it. Thirdly Ruby has optional semi-colons at the end of lines, sometimes if you leave one off you can get a multi-line statement, and sometimes not. This is a design decision that complicates the grammar a lot and can make it hard to tell sometimes where a line ends. And last, but not least, Ruby is a much younger language than Perl. Expect to find bugs from time to time...

        Hey Tilly. If one knows Lisp, Smalltalk, and Perl (hey, I get to mention my three favorite languages all at once! :-) what new ideas would one learn from Ruby? I've had it on a (very) back burner for a while to look at, but the answer to that question hasn't been clear to me, so I've never gotten around to it, though I'd be glad to if I were convinced it would teach me something.

Re: One more perl programmer's take on Ruby (discussion)
by RhetTbull (Curate) on Nov 19, 2001 at 01:04 UTC
    ...there is no 'cran'

    Actually, there is a CRAN but it's for the R programming language (a GNU version of the S/S-Plus languages) which is a mathematical language for computational statistics.

Re: One more perl programmer's take on Ruby (discussion)
by rchiav (Deacon) on Nov 19, 2001 at 06:42 UTC
    I've heard the buzz, but I haven't given Ruby a look until tonight. I know this is going to be an unpopular opinion, but after I spent a little time with it tonight, there's another language that it "felt" like. I honestly think that it has a VB feel to it. I know that's blasphamous, but I always felt that VB was extremely easy to start to program in. Regardless of VB's shortcommings, it's very easy to hit the ground running with the language. I found the same thing with Ruby.

    Just to detail why I thought they felt the same..

    1) No sigils (yeah.. I know there's other languages like this)
    2) no semi-colons (I guess tilly mentioned that they are sometimes optional?)
    3) if foo > 2 instead of if (foo > 2)
    4) end statements for conditionals and iteration.

    Anyway, I'd say it feels like Perl meets VB.
    /me dons his flame retardant suit :)

    Rich

    p.s. - thanks brother dep for giving me a reason to check it out.

Re: One more perl programmer's take on Ruby (discussion)
by snapdragon (Monk) on Nov 19, 2001 at 18:40 UTC
    I had a quick look at Ruby a little while ago. Now I know that it's unfair to make judgements about languages without using them in anger to actually *see* the benefits and costs. However what struck me at the time (and I think it's still kinda true) is that Ruby's did not offer clear benefits over the existing solutions.

    For instance, take a look at Ruby's comparison page. It's improvements over Perl are: nicer syntax, different default scoping, cleaner integration of object-orientedness. The first two hardly make for a decisive argument. The OO integration model is nicer than Perl but I don't think that this alone make for a compelling argument to switch to Ruby.

    I might be prejudiced here, but I basically believe that many who like Perl do so because it's a very free-form language, suitable for quick hacks. Thats my 2 cents anyway.

    However as I mentioned at the top I have never taken a significant amount of time to try and implement anything in Ruby. What about anybody else? Does anyone with experience of Perl and Ruby want to share their feelings?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://126047]
Approved by root
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-23 10:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (125 votes), past polls