Ex-Perl coders: Howz it feel to convert to Ruby?

ruby-talk
21

Andrew Johnson wrote:

[snip]

So the question for any hardcore Perl coders out there that have converted to Perl (or are fluent in both) is: Is it really worth the time? Are the paybacks there? And do you feel you've exceeded your capabilities in Perl using Ruby?

I'll throw my $0.02 into the pot ...

I wouldn't call myself a "hardcore" anything, but I have used Perl a lot,
written about Perl a good deal, and taught a fair number of Perl courses
(introductory and advanced). I do like Perl.

If you are fluent in Perl and have a good grasp of OO (Perl's and/or other
langauges), then fluency in the Ruby language itself should be a relatively
quick and enjoyable experience. What *will* take a while longer is becoming
familiar enough with what is and isn't available in the standard libraries
or on RAA and rubyforge to become as productive as you currently are in
Perl (but that isn't a "language" issue per se).

Absolutely. I agree.

I will mention that I have tried out Python on a couple of occassions, but
was just never seriously drawn to it.

Ruby, on the other hand, appealed to me right away. As different as Ruby
and Perl are, they both "fit" with how my mind thinks and solves problems
--- and I've always been an advocate of balancing the old axiom of "using
the right tool for the job" with "using the right tool for your mind". Ruby
and Perl are both darn good tools in my mind, and for my mind. So for me it
was worth it, ymmv.

I'm totally with you on all this. I've done *exactly* the same thing (Python and all), and I'm thinking both Perl and Ruby fit my "thinking" as well. Good post, mate.

-ceo

···

On Wed, 15 Sep 2004 14:50:25 GMT, Chris <ceo@nospan.on.net> wrote:

22

"Peter Hickman" <peter@semantico.com> schrieb im Newsbeitrag
news:41486964.4040405@semantico.com...

I can hack something up pretty quick in Perl, but I stand a better
chance of maintaining it in Ruby so I get it to work in Perl and then
take the design over to Ruby.

Does this work well? I assume I would do many things quite differently
when in Perl and I wouldn't want to port that design to Ruby.

Kind regards

    robert

23

"James Edward Gray II" <james@grayproductions.net> schrieb im Newsbeitrag
news:CBB35FB8-0732-11D9-B224-000A95BA45F8@grayproductions.net...

I feel Perl has a slight edge in quick and dirty scripting. Simple
things like having to call to_s() on the integers I print or

Under which circumstances do you need to_s for numbers? What's wrong with
this?

puts 1

1
=> nil

print 1, "\n"

1
=> nil

puts "foo #{1} bar"

foo 1 bar
=> nil

Kind regards

    robert

24

"James F. Hranicky" <jfh@cise.ufl.edu> schrieb im Newsbeitrag
news:20040916115917.0ab545bf.jfh@cise.ufl.edu...

On Wed, 15 Sep 2004 23:54:51 +0900

> So I'm looking for feedback from those that have converted, esp. from

a

> hardcore Perl perspective.

Recently it dawned on me that one of the reasons I like Ruby so much is
method chaning. Why? At first, I thought it was because the program
flow went left to right, just like reading. But then it occurred to me
that being able to do something like this:

    `ypcat -k amd_cise`.map { |line|
        line.match(/rhost:=([^;]+)/).captures[0] rescue next
    }.compact.sort.uniq.each { |server|
...

is just like using Unix pipes. When I used perl, and I needed to process
the output of a command like the above, I would generally do all the
work with a regular Unix pipeline. With ruby, the processing is very
similar already. You have to do a little more work, like catching
exceptions and things like nil elements, but the program flow is so
natural there's no need to exec the extra programs.

The only caveat here being to remember that typically with method chaining
you build up one collection before the next step starts; in cases of mass
data this can be rather impractical, whereas pipes only need limited temp
storage (sort and other programs that need to see the whole input are an
exception here).

But otherwise: yes, well observed!

I recently tried hacking on some Perl (I've written thousands of lines
over the years), and I can barely even remember what to do, which is
fine, really :->

:slight_smile:

    robert

···

Chris <ceo@nospan.on.net> wrote:

25

Phil Tomson

Actually things are changing. This place is hiring Ruby programmers for
Rails work, for example:
http://robotcoop.com/

I know of another Ruby job that is probably still open in my area as well.

I'd vote for making a clean break from Perl. It might be that learning
Ruby and Rails will actually turn out to be a good career move (let's
hope).

Very interesting... I don't know where your "area" is, where is all this
happening?

Curt

26

Hmm ... TMTOWTDI applies in both Perl and Ruby. I think I would have
written most of your examples differently, and that difference is
probably why Perl<->Ruby isn't a big deal for me.

(1) The complete OO nature of Ruby IMO changes everything. Perl is
still procedural in it's basic constructs. To iterate from 1 to 10
in
Perl can be shortened *somewhat* from say C or Java using this
construct:

for (0..9) { do_somthing_with( $_ ) }

  foreach my $i (0..9) { do_something_with($i) }

or even

  map { do_something_with($_) } (0..9);

10.times { |i| do_something_with( i ) }

  0.upto(9) { |i| do_something_with(i) }

To me, this is a significant difference and I think this gets
magnified
the deeper one goes into Ruby.

True enough, but presumably your understanding deepends as you go
deeper into Ruby, yes?

(2) I think the need to be familiar with the class methods and
properties is magnified in Ruby. This is similiar to C++ where it's
difficult to be productive unless one gains experience in the classes

and methods available. In Perl, this is not as much the case, again
do
to the fact you can go completely procedural in Perl and get away
with
it. If you do use OO and modules in Perl, then you only need to know

the methods for the module you imported and the rest can be
procedural
in Perl. In Ruby, it seems you can't really get away with that it
seems.

Sure, but POLS is a decent guideline, and when all else fails I call
obj.methods() from irb to see what I get to play with. I generally
don't need to refer to docs for libraries that I haven't imported, so
I'm not sure I understand that bit.

And maybe things aren't as straightforward in Perl as you describe. One
still has to be familiar with the full standard library, the various
sigils, the built-in types, and all of the modules that you've
imported.

(3) Another contrived example, this time in Ruby:

def Contrived
    3.times { yield }
end

[ "tic", "tac", "toe" ].each do |item|
    Contrived { printf "%s ", item }
    printf "\n"
end

There is a lot about this that is different than Perl IMO. I could
create an anonymous subroutine in Perl to function something like the

yield block, and I realize the Ruby above is itself somewhat
contrived,
but... still, you wouldn't normally do something like this in Perl
whereas in Ruby, these sorts of things are actually useful.

Useful, sure. Widely used, you betcha. Fact is that I've still never
needed to use yield in any production code. Use what you need, not what
you feel like you're supposed to. Your sample Perl code didn't show
taint-checking or full conformance to strict and warnings, even though
that is widely promoted as the "right way" to do things.

(4) Each language has it's own strengths. IMO one of Perl's
strengths
is the simplicity and consistency of it's parameter passing:

sub shell {

    my @output;
    for (@_) { push @output, `$_` }
    chomp( @output );
    return wantarray ? @output : \@output;

}

## My favorite "Rubyism" I use all the time in Perl -- puts()!

sub puts { for (@_) { print "$_\n" } }

puts( shell(
    "ls -l",
    "ps -ef | grep -i foo",
    "rm *.bar",
));

Yup, it's a strength of Perl, and that's a nifty puts subroutine :slight_smile:

So the point is I don't want to approach Ruby as Perl even though
there
are similiarities. Unfortunately, I see most people approach Perl in

the same way as C and Java and JavaScript and Perl really looses it's

benefits quickly when approached in this way. I don't want to do the

same with Ruby.

What's wrong with taking advantage of the languages that Ruby builds
on? Familiarity with Perl, Python, Smalltalk, and LISP are all
incredibly useful with Ruby, and sometimes a design is easiest to
express in something resembling one of those languages.

I can see a problem with trying to make your Ruby code look *exactly*
like Perl code, same as writing a C-style for(;:wink: loop instead of a
for/foreach loop in Perl is ugly. But hey, sometimes it's useful. I
don't knock what works, as long as I can read it :slight_smile:

Perhaps these weak examples answer your question. And so the
original
question, clarified more (more muddied more as the case may be),
remains... Howz it feel to convert to Ruby _really_ and not just
applying the "Perl" mindset to Ruby, which I think is a mistake.
It's
clear from even the basic constructs it isn't the same.

Sure, it's not the same. But insisting on doing things the "Ruby Way"
immediately is naturally going to result in a serious dip in
productivity compared to going out and writing code that works, right
away.

But this is a philosophical difference, and I doubt that our
philosophical worlds will intersect much :wink:

Kind Regards,

Brian Wisti
http://coolnamehere.com/

27

Chris wrote:

Peter Hickman wrote:

Being a long time Perl programmer I tend to reach for Perl when I have a problem to solve. Mainly because I can just grab a module off CPAN and hack something up.

However whenever I want to write a simulation (population models, music generators etc.) I go straight for Ruby.

I can hack something up pretty quick in Perl, but I stand a better chance of maintaining it in Ruby so I get it to work in Perl and then take the design over to Ruby.

Interesting, and I think I can/could continue to relate to this. As already stated, I can usually whack out a concise, tight solution in Perl in just a little bit of time. I'm anxious to see if I can get to that place in Ruby and what that would look like. This sounds like Ruby might be more suited to "bigger" tasks and Perl to the small ones. I'm sure others will jump in here momentarily and dispute this...

-ceo

I'm not a hardcore perl user. I learned perl and ruby at the same time. After a few months I dropped Perl and went with Ruby. A coworker of mine uses Perl a heck of a lot (and refuses to try Ruby...ignorance..arghh) and we did a test one day. We both wrote a script to parse out Flash ActionScript code. In one hour I was done with the requirements we had came up with. About an hour later he was finished. He even stated that my code looked cleaner then his, and mine was about 60 lines less of code. Although his code did run about 4 seconds faster per 1000 files of about 200 lines of code.

On another note I think that Perl coders like Perl because if they have a specific problem they can write up a script start to finish relatively quick to solve it. Where Perl lacks here is that if that problem changes or evolves (which they often do) and the requirements change, perl coders don't go refactor their code...they just start a whole new script and rewrite it, which works for small scripts and small problems, but not for larger ones. Perhaps this is how it should be interpreted when you say "sounds like Ruby might be more suited to "bigger" tasks and Perl to the small ones", because I would think more Ruby programmers refactor their code instead of doing a rewrite everytime a requirement changes. (Assuming that the requirement change is a month or two or more after the initial script was written).

Zach

28

Hi,

As already stated, I can usually whack out a concise, tight solution in
Perl in just a little bit of time. I'm anxious to see if I can get to
that place in Ruby and what that would look like. This sounds like Ruby
might be more suited to "bigger" tasks and Perl to the small ones. I'm
sure others will jump in here momentarily and dispute this...

One of the things that thrilled me with ruby was that
it didn't force me to give up quick one-off hack style
scripting, in order to have a cleaner language for bigger
tasks....

I invoke ruby from the command line fairly frequently,
for random things like:

ruby -i -pe 'gsub(/\015/,"")' *.cpp *.h

If I recall my perl correctly (been about three years now)
the perl is slightly shorter:

perl -i -pe 's/\015//g' *.cpp *.h

But ruby has proved sufficiently concise for my needs
in this regard. Actually, sometimes the ruby comes out
shorter than what I think the equivalent perl would be.

Couple days ago a friend who has been learning ruby
asked me about making a program to gather and print a
sorted list of all unique IP addresses in a logfile he
had. (He said a simple string-based sort was OK, and
the logfile structure was simple enough that a very
basic regexp would identify IP addrs without false
positives.) I first approached the problem with a
hash, as I would have in Perl... and then I remembered
ruby has Array#uniq.... So the solution ended up
being:

puts ARGF.read.scan(/\d+\.\d+\.\d+\.\d+/).uniq.sort

=D

Not effing bad, we both thought. :slight_smile:

Regards,

Bill

···

From: "Chris" <ceo@nospan.on.net>

29

Hi --

(3) Another contrived example, this time in Ruby:

def Contrived
    3.times { yield }
end

[ "tic", "tac", "toe" ].each do |item|
    Contrived { printf "%s ", item }
    printf "\n"
end

There is a lot about this that is different than Perl IMO. I could
create an anonymous subroutine in Perl to function something like the
yield block, and I realize the Ruby above is itself somewhat contrived,
but... still, you wouldn't normally do something like this in Perl
whereas in Ruby, these sorts of things are actually useful.

Well, I would do:

  puts ["tic", "tac", "toe"]

or

  puts %w{ tic tac toe }

but I know you meant it just as an illustration of yield :slight_smile: (But
still it's always a pleasure to see how compact and clean Ruby can
be.)

## My favorite "Rubyism" I use all the time in Perl -- puts()!

sub puts { for (@_) { print "$_\n" } }

A perhaps slightly pedantic point: this isn't what puts actually does.
It adds a "\n" to the end of the string only if one isn't there
already.

David

···

On Thu, 16 Sep 2004, Chris wrote:

--
David A. Black
dblack@wobblini.net

30

In article <8x%1d.2604$Qv5.529@newssvr33.news.prodigy.com>,

(4) Each language has it's own strengths. IMO one of Perl's strengths
is the simplicity and consistency of it's parameter passing:

sub shell {

   my @output;
   for (@_) { push @output, `$_` }
   chomp( @output );
   return wantarray ? @output : \@output;

}

Actually, I think this is one of the _worst_ things about Perl and it was
one of those nagging little annoyances that when added up finally led me
to seek out alternatives. The problem with the way parameters are passed
to subroutines in Perl is that you can't tell from a glance how many
params are supposed to be passed into the subroutine and you have no
information about what the params are. You've got to look down through
the subroutine code to see if there's a 'shift @_' lurking somewhere in
the code (for the uninitiated, you pass params to Perl subroutines via the
'@_' global list; you have to 'manually' shift the params off of that list
- blech! )

Phil

···

Chris <ceo@nospan.on.net> wrote:

31

In article <20040915185304.GD4046@lb.tenfour>,

* Phil Tomson <ptkwt@aracnet.com> [0909 19:09]:

.... You know all of the methods that will operate on a particular
object of a certain class (or you can easily find out) and there were more
methods available on builtin classes (for example, look at all of the
methods available on Array objects and compare with functions available in
Perl to operate on @list objects).

That's something that shouldn't be overlooked -

when I went back to perldoc after maybe 9 months away from Perl I had
major problebs remembering the right function to do a particular bit
of manipulation on a Hash. perldoc -f isn't much use without a method name,
and even Google is only useful if can say what you want :slight_smile:

With Ruby it was just 'ri Hash;ri Enumerable' to see all the methods
that worked on a Hash.

Or in irb:
  > Array.methods.sort
=> ["&", "*", "+", "-", "<<", "<=>", "==", "===", "=~", "", "=",
"__id__", "__send__", "all?", "any?", "assoc", "at", "class", "clear",
"clone", "collect", "collect!", "compact", "compact!", "concat", "delete",
"delete_at", "delete_if", "detect", "display", "dup", "each",
"each_index", "each_with_index", "empty?", "entries", "eql?", "equal?",
"extend", "fetch", "fill", "find", "find_all", "first", "flatten",
"flatten!", "freeze", "frozen?", "grep", "hash", "id", "include?",
"index", "indexes", "indices", "inject", "insert", "inspect",
"instance_eval", "instance_of?", "instance_variable_get",
"instance_variable_set", "instance_variables", "is_a?", "join",
"kind_of?", "last", "length", "map", "map!", "max", "member?", "method",
"methods", "min", "nil?", "nitems", "object_id", "pack", "partition",
"pop", "private_methods", "protected_methods", "public_methods", "push",
"rassoc", "reject", "reject!", "replace", "respond_to?", "reverse",
"reverse!", "reverse_each", "rindex", "select", "send", "shift",
"singleton_methods", "size", "slice", "slice!", "sort", "sort!",
"sort_by", "taint", "tainted?", "to_a", "to_ary", "to_s", "transpose",
"type", "uniq", "uniq!", "unshift", "untaint", "values_at", "zip", "|"]

It may not give you all the information about each method, but you can
often get a pretty good idea from the name - if not, then you can use ri
to figure it out.

Phil

···

Dick Davies <rasputnik@hellooperator.net> wrote:

32

Phil Tomson wrote:

In article <20040915160327.GA4046@lb.tenfour>,

* Chris <ceo@nospan.on.net> [0954 15:54]:

I didn't even think about asking this question until now, based on a paragraph I wrote in another thread, so I thought I would ask...

.....I've finally decided that the only way is to ween myself off of Perl and just start using Ruby all the way.

Good on you boy, although your family will starve :slight_smile:
I am still 'Writing Perl for Food', though I hope to start sneaking Ruby under
the radar here now that I've settled in and earned some credit.

Actually things are changing. This place is hiring Ruby programmers for Rails work, for example:
http://robotcoop.com/

I know of another Ruby job that is probably still open in my area as well.

I'd vote for making a clean break from Perl. It might be that learning Ruby and Rails will actually turn out to be a good career move (let's hope).

Actually, you've voiced something openly here that I am privately hoping. It's getting more and more difficult to keep my rates up when people can place jobs out for bid and have someone in India or Russia with an Masters degree in Computer Science complete the work in PHP, Perl or Java for rates that I can't touch. I'm hoping to tap into a "niche" market. One that perhaps doesn't exist yet, but maybe it should. Ruby is really incredible IMO. If I had have a chance of bringing it into my full-time workplace, I most certainly would. Maybe down the road, which is precisely the point.

-ceo

···

Dick Davies <rasputnik@hellooperator.net> wrote:

33

In that case, I suggest you simply read Pickaxe II for pleasure. It's
a good survey of how to accomplish things in Ruby, and the available
libraries to help you.

By the time you finish, you'll have enjoyed thinking differently and
picked up enough Ruby idioms to know what's going on.

Cheers,
Gavin

···

On Thursday, September 16, 2004, 4:29:50 AM, Chris wrote:

Bill Guindon wrote:

On Wed, 15 Sep 2004 23:54:51 +0900, Chris <ceo@nospan.on.net> wrote:

I perceive, from what I've read, that this could be the case. I see all
these "testimonials" that claim rapid development and this is inticing,
yet at the same time, having done *some* Ruby coding, this is a little
hard for me to believe because in my estimation, the paradigm in Ruby is
entirely different than in just about any other procedural language and
even from the OO aspects of Perl, C++ and Java. To me, the difference
between Ruby and just about anything else (common) is the same as when,
in the development world, many of us made the leap from procedural to
OO. I think the gap between Ruby and most everything else is that big
-- as well as the payoffs...?

One of the payoffs is the opportunity to think differently :slight_smile:

Absolutely. One of my primary intriques with Ruby, to be sure...

34

Under which circumstances do you need to_s for numbers? What's wrong with
this?

>> puts 1
1
=> nil
>> print 1, "\n"
1
=> nil
>> puts "foo #{1} bar"
foo 1 bar
=> nil

Try

print "a" + 1

Won't work -- you have to do

print "a" + 1.to_s

Nate

35

It's usually when I'm doing something like:

puts "Total: " + 12345

James Edward Gray II

···

On Sep 16, 2004, at 2:44 AM, Robert Klemme wrote:

"James Edward Gray II" <james@grayproductions.net> schrieb im Newsbeitrag
news:CBB35FB8-0732-11D9-B224-000A95BA45F8@grayproductions.net...

I feel Perl has a slight edge in quick and dirty scripting. Simple
things like having to call to_s() on the integers I print or

Under which circumstances do you need to_s for numbers? What's wrong with
this?

36

"Robert Klemme" <bob.news@gmx.net> wrote in message news:<2qsugrF13g5akU1@uni-berlin.de>...

"James Edward Gray II" <james@grayproductions.net> schrieb im Newsbeitrag
news:CBB35FB8-0732-11D9-B224-000A95BA45F8@grayproductions.net...

> I feel Perl has a slight edge in quick and dirty scripting. Simple
> things like having to call to_s() on the integers I print or

Under which circumstances do you need to_s for numbers?

I can't speak for James, but coming from Java I'm used to using the
concatenation operator, like so:

print "foo" + 1;

This causes an error; you have to call to_s on the number. I find it
unintuitive that specifying multible arguments to the print method is
a way of concatenating them, so I rarely think to use it. I also find
it unintuitive that you don't have to call to_s when passing a
non-string argument by itself, but you do when concatenating. Perhaps
String#+ should be modified to call to_s on its arguments?

BTW, one actual benefit of using concatenation vs. multiple arguments
is that you can use puts instead of print to get a "\n" for free at
the end, but not in between each component of your string.

37

I'm not a hardcore perl user. I learned perl and ruby at the same time. After a few months I dropped Perl and went with Ruby. A coworker of mine uses Perl a heck of a lot (and refuses to try Ruby...ignorance..arghh) and we did a test one day. We both wrote a script to parse out Flash ActionScript code. In one hour I was done with the requirements we had came up with. About an hour later he was finished. He even stated that my code looked cleaner then his, and mine was about 60 lines less of code. Although his code did run about 4 seconds faster per 1000 files of about 200 lines of code.

On another note I think that Perl coders like Perl because if they have a specific problem they can write up a script start to finish relatively quick to solve it. Where Perl lacks here is that if that problem changes or evolves (which they often do) and the requirements change, perl coders don't go refactor their code...they just start a whole new script and rewrite it, which works for small scripts and small problems, but not for larger ones. Perhaps this is how it should be interpreted when you say "sounds like Ruby might be more suited to "bigger" tasks and Perl to the small ones", because I would think more Ruby programmers refactor their code instead of doing a rewrite everytime a requirement changes. (Assuming that the requirement change is a month or two or more after the initial script was written).

Zach

My assumption on Perl "coders" here is my experience with them. I am not trying to stereotype the whole perl world.

Zach

38

Portland, OR, and the surrounding 'burbs. I'm working at Intel using
Ruby right now, (in a position which Phil vacated a few months ago)
and we're looking to hire another coder to work with me. We're not the
only group in-house using Ruby either; we're just (AFAIK) the first of
be hiring Ruby coders specifically.

···

On Thu, 16 Sep 2004 03:46:00 +0900, Curt Hibbs <curt@hibbs.com> wrote:

[...]
Very interesting... I don't know where your "area" is, where is all this
happening?

Curt

--
Lennon
rcoder.net

39

In article <EAENKKNOJPMNCDMLDOMLIENNFNAA.curt@hibbs.com>,

···

Curt Hibbs <curt@hibbs.com> wrote:

Phil Tomson

Actually things are changing. This place is hiring Ruby programmers for
Rails work, for example:
http://robotcoop.com/

I know of another Ruby job that is probably still open in my area as well.

I'd vote for making a clean break from Perl. It might be that learning
Ruby and Rails will actually turn out to be a good career move (let's
hope).

Very interesting... I don't know where your "area" is, where is all this
happening?

Hillsboro, OR. The job was been advertised on this list a couple of weeks
ago - it may be filled by now. The jobs related to that other link are
in Seatle.

Phil

40

In article <8x%1d.2604$Qv5.529@newssvr33.news.prodigy.com>,
>
>(4) Each language has it's own strengths. IMO one of Perl's strengths
>is the simplicity and consistency of it's parameter passing:
>
>sub shell {
>
> my @output;
> for (@_) { push @output, `$_` }
> chomp( @output );
> return wantarray ? @output : \@output;
>
>}
>

In ruby that might be,

def shell(*args)
  args.map {|a| `#{a}`.chomp}
end

...It's true you'll always get an array back. But if
you want to splat the array such that you can assign
its individual element(s) to variables you can...

a = shell("echo 1", "echo 2") # a => ["1", "2"]
a,b = *shell("echo 1", "echo 2") # a => "1", b => "2"

Regards,

Bill

···

Chris <ceo@nospan.on.net> wrote: