Ex-Perl coders: Howz it feel to convert to Ruby?
Chris
paragraph I wrote in another thread, so I thought I would ask...
I've had this long time infatuation with Ruby and as a fairly proficient
Perl coder, have even recreated a few "Ruby things" in Perl over the
last few years. But a couple of "Wow!" factors in Ruby have kept me
hanging around and I've finally decided that the only way is to ween
myself off of Perl and just start using Ruby all the way.
This is hard because I can't afford a lot of downtime, which has been
the biggest strike for me against using Ruby. I'm fairly fast, tight,
and concise at hitting targets using Perl and I don't want to loose that
productivity using Ruby. Still, it appears a "hit" has to be taken if I
really want to learn it as well as I know Perl.
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 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...?
So I'm looking for feedback from those that have converted, esp. from a
hardcore Perl perspective.
Thanks,
-ceo
James Britt
> ... 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...?
Could I can encourage you to go into more detail about this? In what
ways do you see the Ruby paradigm as being s different from Perl, Java,
and C++?
When you started learning Ruby, did you try to adapt familiar Perl/Java
concepts/structures/object models to Ruby? If so, did this help or
hinder your learning Ruby?
>
> So I'm looking for feedback from those that have converted, esp. from a
> hardcore Perl perspective.
Same here. This is an interesting topic.
Thanks,
James
Robert Klemme
"Chris" <c...@nospan.on.net> schrieb im Newsbeitrag
news:REY1d.17014$ZC7....@newssvr19.news.prodigy.com...
> 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 had this long time infatuation with Ruby and as a fairly proficient
> Perl coder, have even recreated a few "Ruby things" in Perl over the
> last few years. But a couple of "Wow!" factors in Ruby have kept me
> hanging around and I've finally decided that the only way is to ween
> myself off of Perl and just start using Ruby all the way.
>
> This is hard because I can't afford a lot of downtime, which has been
> the biggest strike for me against using Ruby. I'm fairly fast, tight,
> and concise at hitting targets using Perl and I don't want to loose that
> productivity using Ruby. Still, it appears a "hit" has to be taken if I
> really want to learn it as well as I know Perl.
IMHO that will be the case with *any* language which you don't use for a
long time: it just takes some initial learning until you reach the same
(or even higher) speed as with a language that you're proficient in. If
you can't afford that at all then I'd suggest to not switch at all *or*
defer the switch, take your time and do Ruby stuff whenever you can afford
until you reach the level of proficiency and speed that you need.
> 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'd say Ruby is worth the journey. I never got really acquainted with
perl OO - which is a major nuisance IMHO. Also Perl has all sorts of
specialities, which make it fast but can lead to ugly surprises ("sort
works only with a restricted kind of block" is one of those exceptions).
Personally I stepped into the "did I dereferenciate often enugh" trap
often enough to slow me down. That might not be the case in your
situation as hardcore perl coder though.
> 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...?
I wouldn't claim that big difference: Ruby OO <-> Perl OO, yes of course -
perl OO is close to nonexistent. There is no unique way to create
instances etc, which makes it hard to work with IMHO. Ruby OO <->
Java/C++ OO, much closer but less hazardous (C++ multiple inheritance) and
more flexible (not only meta data inspection as in Java but also meta data
*manipulation*, such as adding methods dynamically).
> So I'm looking for feedback from those that have converted, esp. from a
> hardcore Perl perspective.
I hope these comments helped even I not from a "hardcore Perl perspective"
but rather from a reasonable Perl background. :-)
Kind regards
robert
Dick Davies
> 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...
Good on you boy, although your family will starve :)
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.
> .... I'm fairly fast, tight,
> and concise at hitting targets using Perl and I don't want to loose that
> productivity using Ruby. Still, it appears a "hit" has to be taken if I
> really want to learn it as well as I know Perl.
>
> 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?
Perl has a lot of annoying rough edges now I'm used to Ruby -
lack of iterators and the func(thingy) rather than obj.method syntax.
But it's also got a few absolutely horrible bits, number one being the whole
OOP model. Despite this a lot of third party libs use the model because it
makes namespace management almost feasible.
It sticks in my eye whenever I try to read another library, sometimes
when I just try to use them, and means things like unit testing are impractical.
So with Perl I just throw something together until it works, test it by hand as
best I can, and hope I can finish it in one sitting, because I won't be able to
follom it when I come back to it :)
> OO. I think the gap between Ruby and most everything else is that big
> -- as well as the payoffs...?
The nice thing about ruby is that it lets you write code without thinking too
much about the language, so your brain has more room for your app logic.
I have almost finished my del.icio.us api library after
about two days of ten minute coding sessions while I was waiting for kernels to compile.
Find a problem to solve and get to it, and post here when you get stuck or think
'there must be a prettier way of saying this' (because in my experience there is).
but to paraphrase the Envoy Corps: '*you* write the code, not the language'.
Use what you find easiest. But I think if you already dig it, then Ruby will
pay off for you.
--
God made the world in six days, and was arrested on the seventh.
Rasputin :: Jack of All Trades - Master of Nuns
Peter Hickman
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.
James Edward Gray II
> 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?
You almost sound like you're looking for the "Silver Bullet" of
programming languages. I'll tell you upfront that I don't think there
is one, so you can let that color the rest of what I say...
I would rate myself as a Perl Expert and an Intermediate Ruby
programmer. I've recently "converted" to Ruby in that I'm now using it
for more and more day-to-day tasks.
Everything else that follows is solely my opinion.
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
remembering when to use times() instead of upto() slow me down or trip
me up just a bit. Of course, this is probably my familiarity as much
as anything else. Please don't get me wrong. I'm not complaining
about the Ruby way of doing things, but I do think I throw down a quick
throw-away or one-use script a touch faster in Perl.
On the flip side, Ruby is by far the cleanest most readable language
I've ever worked with. That gives a huge advantage in bigger and long
term projects, I think. I can just read my code, without having to
figure it out all over again. Because of that, I can make changes
easier and maintain software faster.
Related to that, Perl's object system is downright laughable next to
Ruby. Heck Java doesn't stand up that much better. If you're a OO
guy, there's a lot to like in Ruby and I am.
I spend more of my time writing big programs than small scripts, so it
should be clear why I've begun to prefer Ruby.
The other big difference I've noticed is maturity. Perl and especially
the CPAN are quite mature, simply as a function of time. Ruby is still
"young" in places. I view this as a plus and a minus.
When I need a module XYZ, it's not always immediately available, easy
to find, easy to install, or completely finished. The CPAN can often
claim all of those things at once, which is a stunning feat.
Again though, I also view this as a plus. I sometimes feel like 90% of
the problems have already been solved in Perl and there's not a lot of
room let for my mark. I don't feel that way about Ruby. If a module
is missing, I could be the one to write it. This is more a feeling
than anything else, but it's kind of fun to be on the adventurous side
of a young language, to me at least.
You seem concerned with downtime though, so this may not hold true with
you.
Those are just some of my general impressions. Hopefully, they give
you something of what you're looking for.
In the end I suppose you need to ask yourself why you would switch from
Perl to Ruby, and then see if you think Ruby fits that reasoning. Good
luck with your choice.
James Edward Gray II
Bill Guindon
> I've had this long time infatuation with Ruby and as a fairly proficient
> Perl coder, have even recreated a few "Ruby things" in Perl over the
> last few years. But a couple of "Wow!" factors in Ruby have kept me
> hanging around and I've finally decided that the only way is to ween
> myself off of Perl and just start using Ruby all the way.
>
> This is hard because I can't afford a lot of downtime, which has been
> the biggest strike for me against using Ruby. I'm fairly fast, tight,
> and concise at hitting targets using Perl and I don't want to loose that
> productivity using Ruby. Still, it appears a "hit" has to be taken if I
> really want to learn it as well as I know Perl.
Personally, I don't see it as an either/or thing. I'm learning Ruby
to speed up my coding in another language (Miva - yeah, I know. you've
never heard of it)
So far, my focus has been on building tools for code generation, file
parsing, etc. I can't afford to switch languages, but I think I'll be
much better off with Ruby than without it.
> 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'm hardly hardcore Perl, but I've done quite a bit of it in the past.
If it was my core today, I'd continue to use it for it's speed,
compatibility with existing code, and to appease other dev's working
in the same environment.
I'd pull Ruby in to handle the grunt work, and to bring truth to the
"quick" in "I'll just write a quick script to do X". Granted, it'll
be some time before that can happen, but I think the minimal syntax
helps for those "quick" needs.
I've started by letting it do my local work where speed/compatibility
isn't important, and I'm using it to generate large blocks of
consistent code in my core language.
> 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 :)
--
Bill Guindon (aka aGorilla)
Brian Wisti
--- Chris <c...@nospan.on.net> wrote:
I'm not exactly an ex-Perl coder, since I still use Perl everyday at
work and at home. I have found Ruby to be an excellent item in my
toolkit for testing, prototyping, and creating applications where the
corresponding Perl code would risk melting my brain. Note: High risk of
brain-melt results in significant difficulties maintaining code.
More recently, I've also been exploring the use of Ruby as a shell
scripting language. Guess what? The Ruby code is freakishly similar to
the Perl code for accomplishing the same tasks, minus a few punctuation
symbols. This led me to my first assertion of Perl-to-Ruby transition:
Brian Wisti's First Assertion of Perl-to-Ruby Transition
--------------------------------------------------------
"You're probably trying too hard."
Sorry, I just had to make it look all fancy like that for a second. Ego
is a delicate thing, and it demands attention at all times ;-)
You don't need to take advantage of every language feature to become
proficient in a language. Heck, I was making useful programs in Perl
for a couple years before I started using references and Perl-style
objects. So look at the list, admire the cleverness of the Ruby gurus
with their management of reflection, continuations, Procs, and whatnot.
Then go make the programs you need to make in the way you know how.
Take advantage of the similarities between Ruby and other languages.
Incorporate the really neat features as you develop an understanding of
them. It's okay if your Ruby code looks a little like Perl at first, or
a little like C++. You'll get the hang of the "right way" as your
knowledge improves.
What's the payoff using Ruby instead of Perl? For me, the end result is
stress reduction. It takes roughly the same amount of effort to create
a small program in the two languages, but progressively less effort to
create Ruby applications as the size and scope of the app increases.
The Principle of Least Surprise means that most things are done like
you would expect them to be (or at least like Matz expects them to be,
which is still more consistent than most languages out there).
It is nice to have legible code, too. I know that "legible" is entirely
subjective, and you don't have to agree with it if you don't want to.
You can make clean code in Perl, but it takes a little more work and a
lot more discipline. Plus, all of the "my/local/our" stuff and shifting
subroutine arguments and list context vs. scalar context (and, and,
..) in Perl starts to look more than a little extraneous, interfering
with your reading of the actual code logic. Since Ruby doesn't use any
of that stuff, it's easier for me to see the meat of the code.
So that's my thoughts. And everybody else has their own thoughts as
well, naturally ;-)
Kind Regards,
Brian Wisti
br...@coolnamehere.com
Phil Tomson
Chris <c...@nospan.on.net> wrote:
>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 had this long time infatuation with Ruby and as a fairly proficient
>Perl coder, have even recreated a few "Ruby things" in Perl over the
>last few years. But a couple of "Wow!" factors in Ruby have kept me
>hanging around and I've finally decided that the only way is to ween
>myself off of Perl and just start using Ruby all the way.
>
>This is hard because I can't afford a lot of downtime, which has been
>the biggest strike for me against using Ruby. I'm fairly fast, tight,
>and concise at hitting targets using Perl and I don't want to loose that
>productivity using Ruby. Still, it appears a "hit" has to be taken if I
>really want to learn it as well as I know Perl.
I don't think that the 'hit' is all that big. When I moved from Perl to
Ruby (as a primary agile programming language; I still use C++ ) after
about 3 days of Ruby coding I actually felt more comfortable and more
productive in Ruby than I had in Perl (and I had been coding in Perl for six
years, including OO Perl). I think that Ruby just 'hangs' together a lot
better. 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).
>
>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?
>
First off, I _was_ a big Perl fan, however I haven't used Perl for
anything significant for about 3.5 years now. I've forgotten Perl such
that anytime I look at Perl code these days it just makes my eyes hurt.
So in my case, I made a very clean break from Perl.
To answer your questions: Yes, it's worth the time especially since you
can be productive in Ruby in a day or two. It doesn't take much time to
get productive in Ruby coming from Perl. Sure you'll be coding Perl in
Ruby for the first few months, but keep at it and you'll be learn The Ruby
Way soon enough. The point is, you can be productive in Ruby in a short
time - it may not be code you'll want to show off here on the list, but
it'll get the job done.
Yes, I definately feel that I've exceeded my Perl capabilities. Do OO
Perl for a while and you'll really appreciate moving to Ruby.
>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.
Yes & no. You mention a mix of agile and static languages. Ruby OO is
much nicer than OO Perl where everything is a do-it-yourself project. OO
in an agile language like Ruby feels much different than in C++ or Java
(you have much more freedom in Ruby).
Phil
Chris
> Chris wrote:
>
>> ... 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...?
>
>
> Could I can encourage you to go into more detail about this? In what
> ways do you see the Ruby paradigm as being s different from Perl, Java,
> and C++?
>
> When you started learning Ruby, did you try to adapt familiar Perl/Java
> concepts/structures/object models to Ruby? If so, did this help or
> hinder your learning Ruby?
I think this is precisely the point and your question brings this out
into the clear a little more. It would be a mistake IMO to try and
approach Ruby with "Perl eyes." Sure, there are similiar things in both
languages. It's hard not to think that Matz didn't borrow from Perl, ad
in fact, I think he states this outright (as well as having borrowed
from others as well.) Overall, I think it's a mistake to approach ANY
language from the viewpoint of another to the extent it's possible NOT
to do so. (If that makes sense?) This is the driving force behind my
original question, so your question clarifies this more.
It's easier to make my point in Perl than it is in Ruby, but I'll try a
couple of examples either way:
(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( $_ ) }
But whether the above shorthand is used in Perl, or the traditional "C"
way (eg. "for (my $i=0; $i<10; $i++) { do_something_with( $i ) }") it's
still procedural. I think the Ruby way is significantly different:
10.times { |i| do_something_with( i ) }
To me, this is a significant difference and I think this gets magnified
the deeper one goes into Ruby.
(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.
(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.
(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",
));
You can't do something like that in many languages. Because of the
parameter passing, procedures flow very well and usefully in Perl from
one to the other. The same is true in every aspect of Perl and is in a
very large sense how OO works in Perl. This is a Perl example of what I
feel is probably lurking in Ruby. This is how I would do something like
this in Perl that is not available really in this way anywhere else. My
feeling is that the same sort of thing prevades Ruby. It "does things"
that other languages can't do, including Perl.
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.
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.
-ceo
Andrew Johnson
[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).
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.
regards,
andrew
--
Andrew L. Johnson http://www.siaris.net/
What have you done to the cat? It looks half-dead.
-- Schroedinger's wife
Chris
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
Phil Tomson
Dick Davies <rasp...@hellooperator.net> wrote:
>* Chris <c...@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 :)
>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).
Phil
Chris
> On Sep 15, 2004, at 9:54 AM, Chris wrote:
>
>> 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?
>
>
> You almost sound like you're looking for the "Silver Bullet" of
> programming languages. I'll tell you upfront that I don't think there
> is one, so you can let that color the rest of what I say...
>
> I would rate myself as a Perl Expert and an Intermediate Ruby
> programmer. I've recently "converted" to Ruby in that I'm now using it
> for more and more day-to-day tasks.
>
> Everything else that follows is solely my opinion.
>
> 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 remembering
> when to use times() instead of upto() slow me down or trip me up just a
> bit. Of course, this is probably my familiarity as much as anything
> else. Please don't get me wrong. I'm not complaining about the Ruby
> way of doing things, but I do think I throw down a quick throw-away or
> one-use script a touch faster in Perl.
>
I've run into this too, and it is a bit of a hiccup, but not too bad.
It's easy in Perl to "auto-type" and that's mostly nice.
A great post. Very helpful. I'd probably agree or will end up agreeing
with all of this over time. It is difficult to overcome CPAN versus
Ruby's youngness as you pointed out. But the rest is on the money too
(eg. Perl's "way" of OO'ing, etc.)
-ceo
Chris
Absolutely. One of my primary intriques with Ruby, to be sure...
-ceo
Curt Hibbs
>
> 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
Brian Wisti
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 :-)
> 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(;;) 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 :-)
>
> 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 ;-)
Kind Regards,
Brian Wisti
http://coolnamehere.com/
Dick Davies
> .... 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 :)
With Ruby it was just 'ri Hash;ri Enumerable' to see all the methods
that worked on a Hash.
--
No problem is so formidable that you can't just walk away from it.
-- C. Schulz
Zach Dennis
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
Zach Dennis
> 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
>
not trying to stereotype the whole perl world.
Zach
Lennon Day-Reynolds
> [...]
> Very interesting... I don't know where your "area" is, where is all this
> happening?
>
> Curt
>
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.
--
Lennon
rcoder.net
Bill Kelly
From: "Chris" <c...@nospan.on.net>
>
> 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. :)
Regards,
Bill
Brian Wisti
Man, why can't you guys be up here in Seattle? It's just a few miles
away. I'm sure Intel can move every building, person, and project up
here.
You know we're the cool kids, right? ;-)
-- Brian Wisti
David A. Black
On Thu, 16 Sep 2004, Chris wrote:
> (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 :-) (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
--
David A. Black
dbl...@wobblini.net
Phil Tomson
Chris <c...@nospan.on.net> wrote:
>
>(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
Phil Tomson
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
Phil Tomson
Those Robot Co-op Ruby jobs are in Seattle. Check the link:
http://robotcoop.com/?c=Open+Positions
That place looks really cool: hardwood floors and windows that actually
open to the outside ... Powerbooks... and they seem to be using Ruby.
Once again our region leads the nation in forward thinking ;-)
>You know we're the cool kids, right? ;-)
Of course. Portlanders always secretly worry that Seattle-ites are
cooler than us ;-)
Phil
Bill Kelly
> Chris <c...@nospan.on.net> wrote:
> >
> >(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
Phil Tomson
Dick Davies <rasp...@hellooperator.net> wrote:
>* Phil Tomson <pt...@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 :)
>
>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
Brian Wisti
This is one of those situations where I kinda miss Python and its
ability to store and later display the docstring of a function or class
when requested.
One thing at a time, I suppose.
-- Brian Wisti
Joel VanderWerf
>>Or in irb:
>> > Array.methods.sort
<snip>
> This is one of those situations where I kinda miss Python and its
> ability to store and later display the docstring of a function or class
> when requested.
>
> One thing at a time, I suppose.
Why bloat the ruby executable with docstrings when you can easily add ri
to irb? After all, irb is where you want to access the docs. Here's the
relevant part of my .irbrc:
def ri arg
puts `ri #{arg}`
end
class Module
def ri(meth=nil)
if meth
if instance_methods(false).include? meth.to_s
puts `ri #{self}##{meth}`
end
else
puts `ri #{self}`
end
end
end
Charles Mills
Very cool.
Over here in Portland (where there are lots of Ruby jobs and everyone
is happy) we were talking about working on an *enhanced* version of irb
that would support some/all of the stuff you see here:
http://ipython.scipy.org/ (scroll down to Main Features)
Hasn't gone anywhere though, but I am still pretty excited about the
idea.
IMHO some type of irb addition which groups statements by blocks
instead of by lines would be nice. So when you press 'up' you cycle
through the blocks in your history rather than the individual lines.
(by block I mean if .... end, do .... end, etc) Seems like it would
have to be more than a drop in readline replacement, since it would
have to allow multiline editing of the blocks in history.
Hope that made sense,
Charlie
ChrisO
> 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) }
>
You know, a stylistic thing for sure, but I've stopped using "foreach"
and just use "for" everywhere. And if I can get away with using $_, I
do in lieu of the "my $i" unless I have inner loops and I need a
variable to ferret out abiguity. But I'm OT here, discussing Perl sytle
in a Ruby NG.
> 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?
>
I would agree with that.
>
>>(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.
>
irb is nice just as "perl -e" on the command line is for checking out
features. I've done both as well as "ruby -e".
> 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.
>
I can't argue too much that Perl is kind of it's own thing too, yes.
But it's still easy to keep completely procedural and I would say a
large amount of Perl that I see is.
Thanks. It's tremendously useful for a ton of things written this way.
I still find uses for it that surprise and delight, not to mention
that I have "puts()" in every language I use -- C, JavaScript, Perl, VB,
WSH, etc. I don't even have to remember any more, except I can't do the
above (with the array as a parameter) in anything but Perl.
This is a perspective I need to adopt more, for sure. It's probably the
only realistic way and was exactly the same way I learned Perl. I
didn't develop that puts() call above overnight, as simple as it is,
simply because my ability to conceptualize it that easily didn't exist
until after I had written a significant amount of code. The same will
be true for Ruby.
-ceo
ChrisO
> Hi --
>
> On Thu, 16 Sep 2004, Chris wrote:
>
>
>>(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 :-)
Yep!
(But
> still it's always a pleasure to see how compact and clean Ruby can
> be.)
Yep (again).
>
>
>>## 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.
>
You know, I didn't discover that until this week on my re-entry into
Ruby... But I'd say 95% of the time I use puts in Ruby, it's without
the "\n" at the end, so in Perl I like having the same behavior.
-ceo
ChrisO
An incredibly interesting point of view though your justification for it
is somewhat understandable. Pathological mistakes can occur this way
for those that use this, what I would call an incredibly nice feature,
in an undisciplined way. I'm quite disciplined about spiking out my
arguments in Perl at the top of a subroutine. I think your dislike
perhaps has been fueled by people that write subroutines in a "hackish"
sort of way. (I would imagine "hacking" Ruby is just as possible to
accomplish.)
But aside from the undisciplined uses you've pointed out as reason for
eshewing this in Perl, I have to wholy stand by the amazing power this
feature brings. It far outweighs the negatives. It's one of the
"genius" things about Perl. (Always educational, however, to get
someone else's opposite point of view, as you have offered.)
And to bring this Perl discussion back on topic, in line with your
dislike of this "feature" in Perl, am I not correct in understanding
that in Ruby, one can create methods on the fly in a class? How is this
that much different (conceptually) than unspecified parameters in a Perl
subroutine? How do you know what methods are there (aside from using
the inspection methods available to every class [unless I am mistaken in
this regard]).
-ceo
ChrisO
Ew... thanks for writing that. I had not yet gotten to the point of
converting my Perl shell() routine to Ruby, but this puts (ha!) me ahead
a little bit. I wrote the shell() routine in Perl simply as a reverse
example; I wasn't asking how to do it in Ruby. This "puts" you into the
bonus round... :-)
-ceo
ChrisO
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
Gavin Sinclair
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
Lothar Scholz
I agree with Phil that the unspecified parameters is one of the worst
things in Perl.
C> But aside from the undisciplined uses you've pointed out as reason for
C> eshewing this in Perl, I have to wholy stand by the amazing power this
C> feature brings. It far outweighs the negatives. It's one of the
C> "genius" things about Perl. (Always educational, however, to get
C> someone else's opposite point of view, as you have offered.)
I don't care if you are disciplined enough and can do nice hacks with
this "genius" things. Software is written and maintained by a lot of
different people. If you have to read other persons source code you
are normally lost. I have once seen the argument that a brush
shouldn't restrict the work of painter, and so a language shouldn't
restrict the work of a "genius" programmer but i don't agree with this.
Enforcing styles is good and more productive in the long run.
C> And to bring this Perl discussion back on topic, in line with your
C> dislike of this "feature" in Perl, am I not correct in understanding
C> that in Ruby, one can create methods on the fly in a class? How is this
C> that much different (conceptually) than unspecified parameters in a Perl
C> subroutine? How do you know what methods are there (aside from using
C> the inspection methods available to every class [unless I am mistaken in
C> this regard]).
The difference is that the Ruby method is only used in very very
special cases and should not be seen a good style of programming
without good reasons. I think the TK bindings source code is a good example to
not use this feature. But the perl solution is something that you
must use all the time. So you can't compare the two cases.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
ChrisO
This is where I'm looking to get with Ruby and I still reach for Perl
because I don't know Ruby as well. It happened today at work. I needed
to extract some server names from a piece of Perl code (text) that
looked like this:
{ SERVER => "servername1", SHARE = $Default },
{ SERVER => "servername2", SHARE = $Default },
{ SERVER => "servername3", SHARE = $Default },
{ SERVER => "servername4", SHARE = $Default },
{ SERVER => "servername5", SHARE = $Default },
{ SERVER => "servername6", SHARE = $Default },
{ SERVER => "servername7", SHARE = $Default },
{ SERVER => "servername8", SHARE = $Default },
(The server names were more unique than the contrived names above.) In
Perl it was:
perl -e 'while (<>) { /"(\w*)"/; print "$1\n" }' file-snippet.txt
In Ruby? I didn't have the time to figure it out. Which is the
agonizing point. Later, I did the following in Ruby to satisfactory effect:
ruby -e 'ARGF.each { |line| line.scan( /"(\w*)"/ ) { |frag| puts frag }
}' file-snippet.txt
Perhaps someone can refine this while we're at it. It's hard not to
notice that the Perl was more concise. Perhaps my ignorance can be made
right...? Can this be shortened in Ruby? Surely...
-ceo
ChrisO
> What's the payoff using Ruby instead of Perl? For me, the end result is
> stress reduction. It takes roughly the same amount of effort to create
> a small program in the two languages, but progressively less effort to
> create Ruby applications as the size and scope of the app increases.
> The Principle of Least Surprise means that most things are done like
> you would expect them to be (or at least like Matz expects them to be,
> which is still more consistent than most languages out there).
>
> It is nice to have legible code, too. I know that "legible" is entirely
> subjective, and you don't have to agree with it if you don't want to.
> You can make clean code in Perl, but it takes a little more work and a
> lot more discipline. Plus, all of the "my/local/our" stuff and shifting
> subroutine arguments and list context vs. scalar context (and, and,
> ..) in Perl starts to look more than a little extraneous, interfering
> with your reading of the actual code logic. Since Ruby doesn't use any
> of that stuff, it's easier for me to see the meat of the code.
>
I'm seeing this claim more and more and I'm starting to get sold. Where
there's smoke, there's fire. Multiple people can't be saying this sort
of thing for no reason.
-ceo
ChrisO
More "Wow!" You can't do this in Perl (unless you call in another CPAN
module to pick apart another module. Hardly compariable.)
I becoming quite glad I've started this discussion. I'm thinking I'm
just about taken in with this. Beautiful.
-ceo
ChrisO
> On Wed, 15 Sep 2004 14:50:25 GMT, Chris <c...@nospan.on.net> 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
Joel VanderWerf
> This is where I'm looking to get with Ruby and I still reach for Perl
> because I don't know Ruby as well. It happened today at work. I needed
> to extract some server names from a piece of Perl code (text) that
> looked like this:
>
> { SERVER => "servername1", SHARE = $Default },
> { SERVER => "servername2", SHARE = $Default },
> { SERVER => "servername3", SHARE = $Default },
> { SERVER => "servername4", SHARE = $Default },
> { SERVER => "servername5", SHARE = $Default },
> { SERVER => "servername6", SHARE = $Default },
> { SERVER => "servername7", SHARE = $Default },
> { SERVER => "servername8", SHARE = $Default },
>
> (The server names were more unique than the contrived names above.) In
> Perl it was:
>
> perl -e 'while (<>) { /"(\w*)"/; print "$1\n" }' file-snippet.txt
>
> In Ruby? I didn't have the time to figure it out. Which is the
> agonizing point. Later, I did the following in Ruby to satisfactory
> effect:
>
> ruby -e 'ARGF.each { |line| line.scan( /"(\w*)"/ ) { |frag| puts frag }
> }' file-snippet.txt
>
> Perhaps someone can refine this while we're at it. It's hard not to
> notice that the Perl was more concise. Perhaps my ignorance can be made
> right...? Can this be shortened in Ruby? Surely...
Golf.shoes = "on"
$ ruby -n -e 'puts $1 if /"(\w+)"/' file-snippet.txt
servername1
servername2
servername3
servername4
servername5
servername6
servername7
servername8
Bill Guindon
>
> This is where I'm looking to get with Ruby and I still reach for Perl
> because I don't know Ruby as well. It happened today at work. I needed
> to extract some server names from a piece of Perl code (text) that
> looked like this:
>
> { SERVER => "servername1", SHARE = $Default },
> { SERVER => "servername2", SHARE = $Default },
> { SERVER => "servername3", SHARE = $Default },
> { SERVER => "servername4", SHARE = $Default },
> { SERVER => "servername5", SHARE = $Default },
> { SERVER => "servername6", SHARE = $Default },
> { SERVER => "servername7", SHARE = $Default },
> { SERVER => "servername8", SHARE = $Default },
>
> (The server names were more unique than the contrived names above.) In
> Perl it was:
>
> perl -e 'while (<>) { /"(\w*)"/; print "$1\n" }' file-snippet.txt
>
> In Ruby? I didn't have the time to figure it out. Which is the
> agonizing point. Later, I did the following in Ruby to satisfactory effect:
>
> ruby -e 'ARGF.each { |line| line.scan( /"(\w*)"/ ) { |frag| puts frag }
> }' file-snippet.txt
>
> Perhaps someone can refine this while we're at it. It's hard not to
> notice that the Perl was more concise. Perhaps my ignorance can be made
> right...? Can this be shortened in Ruby? Surely...
ruby -e 'puts ARGF.grep(/"(\w*)"/) {$1}' file-snippet.txt
I'd bet it could be shorter still, but It's all new to me too :)
--
Bill Guindon (aka aGorilla)
Gavin Sinclair
>> perl -e 'while (<>) { /"(\w*)"/; print "$1\n" }' file-snippet.txt
>>
>> In Ruby? I didn't have the time to figure it out. Which is the
>> agonizing point. Later, I did the following in Ruby to satisfactory
>> effect:
>>
>> ruby -e 'ARGF.each { |line| line.scan( /"(\w*)"/ ) { |frag| puts frag }
>> }' file-snippet.txt
>>
>> Perhaps someone can refine this while we're at it. It's hard not to
>> notice that the Perl was more concise. Perhaps my ignorance can be made
>> right...? Can this be shortened in Ruby? Surely...
> Golf.shoes = "on"
> $ ruby -n -e 'puts $1 if /"(\w+)"/' file-snippet.txt
$ ruby -ne 'puts $1 if /"(\w+)"/' file-snippet.txt
Easiest game of golf I ever played :)
Gavin
Bill Guindon
<gsin...@soyabean.com.au> wrote:
> $ ruby -ne 'puts $1 if /"(\w+)"/' file-snippet.txt
>
> Easiest game of golf I ever played :)
Ooooh! *golf clap* :)
Phil Tomson
Did you do this in comments? In my faint recollections of Perl I seem to
recall that there was a way to declare the sub with it's params - but most
people didn't do this (or perhaps my memory is incorrect).
> I think your dislike
>perhaps has been fueled by people that write subroutines in a "hackish"
>sort of way. (I would imagine "hacking" Ruby is just as possible to
>accomplish.)
>
>But aside from the undisciplined uses you've pointed out as reason for
>eshewing this in Perl, I have to wholy stand by the amazing power this
>feature brings. It far outweighs the negatives. It's one of the
>"genius" things about Perl. (Always educational, however, to get
>someone else's opposite point of view, as you have offered.)
Essentially what you're trying to get is to be able to pass in a variable
number of arguments to a method (err, function in Perlese). Ruby lets
you do that like so:
def foo(*args)
At least in this case you can tell at a glance that foo can take a
variable number of arguments.
In perl you could have:
sub foo {
for(@_) {... do whatever...}
}
In the case of Perl, I've got to actually go and read the body of the
function to know that it can take multiple arguments. I don't like it.
The other thing I don't like about it is that it means that argument
handling in Perl is a do-it-yourself project (like OO Perl)
>
>And to bring this Perl discussion back on topic, in line with your
>dislike of this "feature" in Perl, am I not correct in understanding
>that in Ruby, one can create methods on the fly in a class? How is this
>that much different (conceptually) than unspecified parameters in a Perl
>subroutine?
It could present similar problems, however, creating methods on the fly,
while possible, it's relatively unusual compared to what we're talking
about in Perl. Every sub in Perl requires that I read the body of the sub
to determine what the args are and how many. I would also contend that
the 'problem' of creating methods on the fly is not as big because what is
happening is that you're getting some new feature (a new method) created
on the fly (or perhaps you're overriding an old one) that you may not be
aware of - not knowing about a new method won't break anything because
you probably won't call what you don't know about. ;-)
>How do you know what methods are there (aside from using
>the inspection methods available to every class [unless I am mistaken in
>this regard]).
I'll give you a better example for your the point you're trying to make: yield.
In Ruby you can have:
def foo
#...
yield
#...
end
Now there is no indication from looking at the method definition line (the
'def foo' part) that any argument is passed to this method, yet it
requires that a block be passed to it, like so:
foo { puts "Boo!" }
So, it's a bit like the problem I'm talking about with Perl, except that
in practice it's not as bad because usually there is only one yield in a
method - but it can be an issue. That's why it's probably better to do:
def foo(&b)
#...
b.call
#...
end
Because it provides the reader of the code with a clear indication that
the method takes a block. Also, it's usually a good idea if you do use
yield to also call 'block_given?' prior to yielding.
Phil
James Edward Gray II
> Did you do this in comments? In my faint recollections of Perl I seem
> to
> recall that there was a way to declare the sub with it's params - but
> most
> people didn't do this (or perhaps my memory is incorrect).
This solid reasoning for this aversion. Prototypes are more than a
little flawed in Perl. They aren't even checked on a method call,
which seriously degrades their usefulness. There are other issues, but
that was the biggie, for me anyway.
James Edward Gray II
Marcel Molina Jr.
also if your .irbrc includes "require 'irb/completion'" you can tab
complete methods:
e.g.
>> "The Boat Arrived!".s<Tab><Tab>
.scan .sort .sub
.select .sort_by .sub!
.send .split .succ
.singleton_methods .squeeze .succ!
.size .squeeze! .sum
.slice .strip .swapcase
.slice! .strip! .swapcase!
>> "The Boat Arrived!".sum - 1
=> 1492
marcel
--
Marcel Molina Jr. <mar...@vernix.org>
John W. Kennedy
--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood.html
ChrisO
>>>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! )
>>>
>>
>>An incredibly interesting point of view though your justification for it
>>is somewhat understandable. Pathological mistakes can occur this way
>>for those that use this, what I would call an incredibly nice feature,
>>in an undisciplined way. I'm quite disciplined about spiking out my
>>arguments in Perl at the top of a subroutine.
>
>
> Did you do this in comments? In my faint recollections of Perl I seem to
> recall that there was a way to declare the sub with it's params - but most
> people didn't do this (or perhaps my memory is incorrect).
>
No, I usually spike them out at the top of the subroutine. Like this:
sub foo {
## Get parameters.
my $bar = shift; ## Comment variable use here
my $boat = shift; ## Same here
## Return bar and boat concat'd.
"$bar$boat";
}
In general, that's how ALL my Perl subroutines look. It IS a
disciplined approach and I guess I have to say that by doing so I am
implying some rightness in other people's comments here because I
dislike the same loosy-goosy approach in what I call "trash code" that
other people write in Perl. You look at their Perl code, and you can't
make hide nor hair of it without sitting down, marking out variables,
etc. as some have stated.
I guess I'm willing to live with the power at the expense of the
potential for a mess, but it can get messy when it ends up that there
are 50 ways to "pass" the variable(s) in. Some of which I dislike
immensely myself such as this approach:
sub foo {
my( $bar, $boat ) = @_;
"$bar$boat";
}
Still, sometimes those different approaches make sense. In OO modules,
I've been known to do, assuming foo is a method I am defining in an OO
module, the following:
sub foo { "$_[0]$_[1]" }
When I see that, because of all the Perl coding I've done, I know
IMMEDIATELY what's going on. It appears, to my surprise in this NG
(though I'd never really thought about it much until now) that some
people don't like this.
Generally, just because of the way I am "wired" if a language is
somewhat regimented, I like that and can go with it (I recall earlier
days in Pascal, and I considered C somewhat that way as well), and if
the language is "loosy goosy" like Perl, I super-impose my own
regimented, methodical way of coding. I think mainly because I've found
that consistency in approach (to the nth detail) leads to robustness and
maintainability. And how much time does it take to spike out my
variables as I demo'd above versus just slapping them around somewhere
in the body of the subroutine? Or indenting consistently throughout,
etc.? It doesn't take much, and yet there are A LOT of people that
don't, so the comments here have some merit, I do admit.
Incidentally, perhaps the thing you are referring to in Perl, denoting
parameters is the following notation:
sub foo($$) {
## Body of subroutine here.
}
This denotes two parameters are intended. I'm not overly familiar with
this, and I don't use it. It still doesn't spike out parameters as you
all here are advocating.
>
> Essentially what you're trying to get is to be able to pass in a variable
> number of arguments to a method (err, function in Perlese). Ruby lets
> you do that like so:
>
> def foo(*args)
>
> At least in this case you can tell at a glance that foo can take a
> variable number of arguments.
>
> In perl you could have:
>
> sub foo {
>
> for(@_) {... do whatever...}
>
> }
>
>
> In the case of Perl, I've got to actually go and read the body of the
> function to know that it can take multiple arguments. I don't like it.
>
But the Perl construct you have above is powerful in certain situations
just as you indicate later here concerning Ruby and the block/yield
methodology. Only in Ruby you have the ability to make it more readable
with the foo.call method as you pointed out. But in Perl, the following
is extremely powerful used in the right context:
sub puts { for (@_) { print "$_\n" } }
Because the intent is to use all parameters passed until all have been
iterated over. Unfortunately, that same @_ notation can be used in ways
I don't like too. So, I guess I have to say, I do understand somewhat.
> The other thing I don't like about it is that it means that argument
> handling in Perl is a do-it-yourself project (like OO Perl)
>
<Sigh> Yep. Which is one of the reasons Ruby is appealing to me. It's
A LOT OF STINKING WORK to create even the simplest Perl OO module, I
have to admit. Versus:
class Foo
attr_reader :bar, :boat
def initialize( bar, boat )
@bar, @boat = bar, boat
end
def concat
@bar + @boat
end
end
foo = Foo.new
p foo.concat
p foo.bar
p foo.boat
Wow. And you have accessors and everything right there. In Perl, the
above is easily 10-20 lines of code and the less lines, the more
ambigious it would be. The above Ruby is just plain nice.
>
>>And to bring this Perl discussion back on topic, in line with your
>>dislike of this "feature" in Perl, am I not correct in understanding
>>that in Ruby, one can create methods on the fly in a class? How is this
>>that much different (conceptually) than unspecified parameters in a Perl
>>subroutine?
>
>
> It could present similar problems, however, creating methods on the fly,
> while possible, it's relatively unusual compared to what we're talking
> about in Perl. Every sub in Perl requires that I read the body of the sub
> to determine what the args are and how many. I would also contend that
> the 'problem' of creating methods on the fly is not as big because what is
> happening is that you're getting some new feature (a new method) created
> on the fly (or perhaps you're overriding an old one) that you may not be
> aware of - not knowing about a new method won't break anything because
> you probably won't call what you don't know about. ;-)
>
OK, my question was from the vantage of not knowing for sure, so this
explains that wonderment.
Yes, this is a better example of what I was talking about, and yes, you
can provide better indication here in Ruby than in Perl, I have to
admit. So, to see the parallels, I'll bet you see a lot more of the
simple yields in block handling method definitions in classes than you
do in the form of you second example with the spiked out parameter and
the param.call approach. It's disciplined, well constructed code, but
not everyone is like that. Hence the Perl dilemma/diatribe here.
-ceo
ChrisO
Wow. So tonight I learn about the -n switch. Nice. And I didn't think
the $1 would be available as in Perl. So it's good to know that's in
Ruby too. Sweet.
-ceo
ChrisO
I'll look for it. This thread has been a load of fun and more than
helped me get the perspective I was looking for.
-ceo
ChrisO
> <Sigh> Yep. Which is one of the reasons Ruby is appealing to me. It's
> A LOT OF STINKING WORK to create even the simplest Perl OO module, I
> have to admit. Versus:
>
> class Foo
> attr_reader :bar, :boat
>
> def initialize( bar, boat )
> @bar, @boat = bar, boat
> end
>
> def concat
> @bar + @boat
> end
> end
>
> foo = Foo.new
> p foo.concat
> p foo.bar
> p foo.boat
>
> Wow. And you have accessors and everything right there. In Perl, the
> above is easily 10-20 lines of code and the less lines, the more
> ambigious it would be. The above Ruby is just plain nice.
>
Should have been:
foo = Foo.new( "bar", "boat" )
Foo.initialize expects args passed. They were not spiked out with
defaults. As in:
def initialize( bar="bar", boat="boat" )
@bar, @boat = bar, boat
end
I'm tempted to type in the required Perl equivalent code here for the
Foo class above for contrast, only no one here needs convincing. I'm
still shaking my head. I'm certainly pretty much convinced.
-ceo
Gavin Sinclair
> <Sigh> Yep. Which is one of the reasons Ruby is appealing to me. It's
> A LOT OF STINKING WORK to create even the simplest Perl OO module, I
> have to admit. Versus:
>
> class Foo
> attr_reader :bar, :boat
>
> def initialize( bar, boat )
> @bar, @boat = bar, boat
> end
>
> def concat
> @bar + @boat
> end
> end
>
> foo = Foo.new
> p foo.concat
> p foo.bar
> p foo.boat
>
> Wow. And you have accessors and everything right there. In Perl, the
> above is easily 10-20 lines of code and the less lines, the more
> ambigious it would be. The above Ruby is just plain nice.
Damn right. It's amazing how after years of programming the simple things
still take ages to properly sink in. I needed a counter for several
indices a few days ago. I only needed it in one place. Instead of using
a hash and managing all the logic inline (where lots of other logic was
taking place), a simple class worked wonders.
#
# Maintains a bunch of indexed counters.
#
# counter = Counter.new
# counter.next('x') # -> 1
# counter.next('y') # -> 1
# counter.next('x') # -> 2
# counter.next('z') # -> 1
# counter.next('y') # -> 2
# counter.next('x') # -> 3
#
class Counter
def initialize
@counters = {}
end
def next(idx)
@counters[idx] ||= 0
@counters[idx] += 1
end
end
My favourite refactoring pattern at the moment is to move all the related
private methods of a class into their own class. It helps to clarify the
real responsibility of the original class, to highlight the relationship
between them, and to test the supporting code more easily. (The difficult
part is thinking of a name for the new class.)
To do all this, you need a language where creating new classes is easy and
intuitive. Having a language that's ball-tearingly powerful doesn't hurt,
either.
Cheers,
Gavin
Michael Geary
> I'm tempted to type in the required Perl equivalent code here
> for the Foo class above for contrast, only no one here needs
> convincing. I'm still shaking my head. I'm certainly pretty
> much convinced.
I don't need convincing, but I'd be interested in seeing the equivalent Perl
code just for the sake of comparison. I find it educational to see how
different languages approach a problem.
Thanks,
-Mike
Joel VanderWerf
> On Thursday, September 16, 2004, 10:39:02 AM, Joel wrote:
>>$ ruby -n -e 'puts $1 if /"(\w+)"/' file-snippet.txt
>
>
> $ ruby -ne 'puts $1 if /"(\w+)"/' file-snippet.txt
>
> Easiest game of golf I ever played :)
Heh. I bogied by splitting up the -ne. Was that a "hole in -ne"?
(And that's enough from me tonight!)
Joel VanderWerf
..
> Over here in Portland (where there are lots of Ruby jobs and everyone is
> happy) we were talking about working on an *enhanced* version of irb
> that would support some/all of the stuff you see here:
> http://ipython.scipy.org/ (scroll down to Main Features)
> Hasn't gone anywhere though, but I am still pretty excited about the idea.
> IMHO some type of irb addition which groups statements by blocks instead
> of by lines would be nice. So when you press 'up' you cycle through the
> blocks in your history rather than the individual lines. (by block I
> mean if .... end, do .... end, etc) Seems like it would have to be more
> than a drop in readline replacement, since it would have to allow
> multiline editing of the blocks in history.
That would be very nice. I've wanted that ever since I started using zsh
in place of bash. I wonder if there is some reusable code in zsh to
replace readline....
Robert Klemme
"Peter Hickman" <pe...@semantico.com> schrieb im Newsbeitrag
news:41486964...@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
Robert Klemme
"James Edward Gray II" <ja...@grayproductions.net> schrieb im Newsbeitrag
news:CBB35FB8-0732-11D9...@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
Garance A Drosehn
> 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 learned perl well before ruby. I wouldn't say that I'm a hardcore
perl programmer, but I had written some fairly long perl scripts. And
I still work with perl, because that's what most of the other systems
programmers here are familiar with.
For me, I think it's just a question of "how I think". I usually have
to start out on some script with either no idea what I'm doing, or
with explicit instructions which turn out to be wrong (such as "the
data will always be sorted, and in the correct order" -- only to find
out the incoming data is usually in the exactly-wrong order...). So,
whether ruby or perl, I start out to write one thing, and later find
out that I need to change that considerably. When programming in
perl, I end up with the script getting messier and messier. With ruby
I manage to keep refactoring the problem fairly easy, so the script
keeps looking better the more I have to work on it.
I think this is partially because I used to do a lot with ObjectiveC,
so it is pretty natural for me to use object-oriented tactics, if I
have a language where that's easy to do. While I have done a lot with
perl, I never did quite wrap my mind around how to write
"object-oriented Perl". But writing Ruby seems very straightforward
to me.
YMMV...
> [...] 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.
I know some programmers who do a fine job writing OO-perl, and end up
with code that is quite readable. My attempts end up a mess. Maybe
my brain is just wired wrong.
Personally, I find C++ to be horrid. I do not consider it a usable OO
language. That's just my opinion, of course. I have certainly read
through a lot of C++ code where the author has absolutely no idea what
OO programming is about.
Java looks pretty reasonable in my opinion, but in my job I have no
real reason to use it for anything. So, I haven't really tried to
write anything major in it.
The object-oriented language that I had a lot of experience with is
Objective-C, in the days when NeXT Computers was still making hardware
(12 years ago...). The combination of Objective-C and the
InterfaceBuilder goes a long way to guiding the programmer so you
really start to understand what OOP is about. You pick up what you
should be trying to do with objects, and what you gain by doing it
correctly. For me, coming from that Objective-C background, Ruby was
easy to pick up.
I have no background with Smalltalk, but I suspect that programmers
who know that OO language would also find Ruby easy to pick up.
--
Garance Alistair Drosehn = dro...@gmail.com
Senior Systems Programmer or g...@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA
David A. Black
On Thu, 16 Sep 2004, ChrisO wrote:
There's nothing wrong with doing this the way Phil has, but there's
also nothing wrong or undisciplined about using yield. Let's not
stigmatize people who use yield (for example, Matz and many of the
other authors of the Ruby standard library) as undisciplined. It's
not a test of character; it's a programming idiom. You can work
around it if you don't like it, as Phil has shown, or you can use it,
as others have shown, in the course of writing perfectly good and
clear code.
When you supply a block to a method, you need to know how the block is
going to be called -- which means you'll probably either have written
the method yourself, or consulted some documentation that explains how
the method works. So in practical terms, the use of yield vs. calling
the block explicitly probably doesn't matter too much too often. You
can use whichever semantics you like.
David
--
David A. Black
dbl...@wobblini.net
Curt Hibbs
>
> My favourite refactoring pattern at the moment is to move all the related
> private methods of a class into their own class. It helps to clarify the
> real responsibility of the original class, to highlight the relationship
> between them, and to test the supporting code more easily. (The difficult
> part is thinking of a name for the new class.)
I hadn't thought of this, but it is immediately obvious to me that this can
be very useful. I'm going to try this on the Java project I'm doing for
work!
Thanks,
Curt
Nate Smith
> 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
James Edward Gray II
>
> "James Edward Gray II" <ja...@grayproductions.net> schrieb im
> Newsbeitrag
> news:CBB35FB8-0732-11D9...@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?
It's usually when I'm doing something like:
puts "Total: " + 12345
James Edward Gray II
Chris
I actually wrote it anyway right after I posted the message above, just
to see what the difference would be:
#!/usr/bin/perl
package Foo;
use strict;
use warnings qw( all );
sub new {
my $class = shift;
my $self = {};
$self->{__bar} = shift || 'bar';
$self->{__boat} = shift || 'boat';
bless $self, $class;
}
sub bar { $_[0]->{__bar} }
sub boat { $_[0]->{__boat} }
sub concat { $_[0]->{__bar} . $_[0]->{__boat} }
package main;
use strict;
use warnings qw( all );
my $foo = Foo->new( @ARGV );
puts(
$foo->concat(),
$foo->bar(),
$foo->boat(),
);
sub puts { for (@_) { print "$_\n" } }
__END__
The accessors could be handled by AUTOLOAD, but I doubt it would have
shortened the code that much. This is written with two packages
(namespaces) in one file, which IMO more closely mirrors the equiv. Ruby
code, but isn't as common in the Perl world (in my experience anyway).
-ceo
Austin Ziegler
You're really better off using interpolation there:
@total = 12345
puts "Total: #{@total}"
Now, you don't have to know whether @total is a Fixnum, String, Float,
or even a hypothetical Money class.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
: as of this email, I have [ 6 ] Gmail invitations
James Edward Gray II
On Sep 16, 2004, at 12:34 AM, Michael Geary wrote:
> I don't need convincing, but I'd be interested in seeing the
> equivalent Perl
> code just for the sake of comparison. I find it educational to see how
> different languages approach a problem.
#!/usr/bin/perl
use strict;
use warnings;
package Foo;
sub new {
my $class = shift;
my %object = ( bar => "default",
boat => "values",
@_ );
return bless \%object, $class;
}
sub bar { return shift->{bar}; }
sub boat { return shift->{boat}; }
sub concat {
my $self = shift;
return $self->{bar} . $self->{boat};
}
package main;
my $foo = Foo->new(bar => "bar", boat => "boat");
print $foo->concat, "\n";
print $foo->bar, "\n";
print $foo->boat, "\n";
# minor example of code difference
$foo->{bar} = "Not Private!";
print "\n", $foo->bar, "\n";
__END__
Hope that helps.
James Edward Gray II
James Edward Gray II
> You're really better off using interpolation there:
>
> @total = 12345
> puts "Total: #{@total}"
>
> Now, you don't have to know whether @total is a Fixnum, String, Float,
> or even a hypothetical Money class.
An excellent point. Thanks for the tip.
James Edward Gray II
P.S. As I said in the original post, most of my issues probably come
from my lack of familiarity.
Robert Klemme
"Nate Smith" <nsm...@nist.gov> schrieb im Newsbeitrag
news:1095340527.2...@circuit.eeel.nist.gov...
I prefer to use #{} in those cases (see above, no. 3). Gives you more
control.
Of course, your example can be written much easier:
print "a", 1
Kind regards
robert
Andrew Johnson
[snip]
> to see what the difference would be:
Alternatively (tmtowtdi and all that ...):
#!/usr/bin/perl -w
use strict;
my $foo = Foo->new('the');
print $foo->concat, "\n";
$foo->bar = 'Das';
$foo->boat = 'Boot';
print $foo->concat, "\n";
{
package Foo;
my(%bar, %boat);
sub new {
my $self = bless {}, shift;
$self->$_ = shift || $_ for ('bar','boat');
$self;
}
sub bar : lvalue { $bar {$_[0]}}
sub boat : lvalue { $boat {$_[0]}}
sub concat { $_[0]->bar . $_[0]->boat }
}
__END__
regards,
andrew
James F. Hranicky
> 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.
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 :->
Jim
Robert Klemme
"James F. Hranicky" <j...@cise.ufl.edu> schrieb im Newsbeitrag
news:2004091611591...@cise.ufl.edu...
> On Wed, 15 Sep 2004 23:54:51 +0900
> Chris <c...@nospan.on.net> wrote:
>
> > 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 :->
:-)
robert
Karl von Laudermann
> "James Edward Gray II" <ja...@grayproductions.net> schrieb im Newsbeitrag
> news:CBB35FB8-0732-11D9...@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.
Chris
Oooooo... Aaaaaah...! lvalues... You don't see folks using them very
much. I don't use them much myself.
-ceo
Martin DeMello
> > > Array.methods.sort
>
> More "Wow!" You can't do this in Perl (unless you call in another CPAN
> module to pick apart another module. Hardly compariable.)
Another useful trick is to do Array.methods - Object.methods (array
subtraction - gotta love it); that removes all the common methods Array
inherited from Object.
martin
Phil Tomson
I agree totally. I did not intend to stigmatize people for using 'yield'.
In fact, I tend to use 'yield' as often as the alternative. I think I
sometimes prefer yield because even though it tends to make the arguments
to the method somewhat ambiguous, the intent can sometimes seem clearer in
the body of the method (vs the 'call').
Phil
David A. Black
I was referring mainly to Chris's characterization of yield users as
different from people who write disciplined, well-constructed code. I
suspect that Chris didn't really mean it as a slam to yield users
either, but it kind of read that way. (And I'm at least a frequent
yield user myself :-)
Markus
> Is there any way to change an outside-scoped object inside a proc? Such
> as:
>
> a = "Foo"
> b = "bar"
> proc = Proc.new { |val1, val2| val1, val2 = "boo", "baz" }
> proc.call( a, b )
>
> # a and b are still "Foo" and "bar"
>
> I don't believe this is possible.. but would be very nice for creating a
> collect! method for a user-defined object. Thanks
I suspect you are right (that it isn't possible), at least without
going through some rather extreme contortions. Over all, I'm _glad_
that this is the case (though I must admit I've past parameters in "var"
with wild abandon in other languages).
Why do you think this is needed (or nice) for writing a collect!
method? Why cant you just write something like:
class My_collection_class
def [](k)
:
end
def []=(k,v)
:
end
def each_key
:
end
def collect!
each_key { |k| self[k] = yield(self[k]) }
end
end
-- MarkusQ
Matt Maycock
> as:
>
> a = "Foo"
> b = "bar"
> proc = Proc.new { |val1, val2| val1, val2 = "boo", "baz" }
> proc.call( a, b )
>
> # a and b are still "Foo" and "bar"
>
> I don't believe this is possible.. but would be very nice for creating a
> collect! method for a user-defined object. Thanks
a, b = "foo", "bar"
proc = Proc.new {|a, b|}
proc.call(1, 2)
# a, b => 1, 2
Mauricio Fernández
> I was referring mainly to Chris's characterization of yield users as
> different from people who write disciplined, well-constructed code. I
> suspect that Chris didn't really mean it as a slam to yield users
> either, but it kind of read that way. (And I'm at least a frequent
> yield user myself :-)
And you can be "disciplined" by Chris' criteria while using yield:
def foo(arg, &block)
yield
end
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
Lennon Day-Reynolds
You have to use mutable objects. Variables in Ruby, whether in blocks
or elsewhere, are references, not pointers. If you reassign a
variable, you're just changing which object it refers to, rather than
updating the value of a memory location.
Luckily, Ruby strings are mutable, so at least for your example, you
could do the following:
a = "Foo"
b = "Bar"
myproc = Proc.new {|val1, val2| # note: I try to avoid shadowing a
built-in like 'proc'
val1[1..-1] = "boo" # with a variable name
val2[1..-1] = "baz"
}
proc.call(a, b)
It might be interesting to define something like Common Lisp's 'setf'
function, which is a sort of generic setter. So, mutable objects like
strings, arrays, hashes, etc., could all support a 'value=' or
'replace' method which would make them destructively update their
value.
--
Lennon
rcoder.net
Chris
Yeah, my rhetoric kinda made it sound that way. I'm not in a position
yet to critique Ruby coding technique. But I do see a lot of
undisciplined use of Perl syntax, and that was my main point. I just
carried it over a little too far. Phil's point that the foo.call method
*may* make things stand out a little better is still a noteworthy point
however. But I don't think he was saying 'yield' was undisciplined coding.
-ceo
Lennon Day-Reynolds
same name. If you want to be able to pass the variables to be updated
to proc, as the original poster requested, then it won't work.
It is a great way to really confuse the hell out of someone reading
your code, though; the variable/parameter scoping issues surrounding
blocks are one of the few things I really consider to be a "wart" in
the core Ruby language.
--
Lennon
rcoder.net
Joel VanderWerf
> On Fri, Sep 17, 2004 at 03:20:05AM +0900, David A. Black wrote:
>
>>I was referring mainly to Chris's characterization of yield users as
>>different from people who write disciplined, well-constructed code. I
>>suspect that Chris didn't really mean it as a slam to yield users
>>either, but it kind of read that way. (And I'm at least a frequent
>>yield user myself :-)
>
>
> And you can be "disciplined" by Chris' criteria while using yield:
>
> def foo(arg, &block)
> yield
> end
..although this does have a small speed penalty as a Proc object gets
created by the &block construct, IIRC.
Why not just use the rdoc markup as a convention, if you want to be
explicit?
def foo(arg) # :yields: some_useful_object
yield foo(arg)
end
Markus
> function, which is a sort of generic setter. So, mutable objects like
> strings, arrays, hashes, etc., could all support a 'value=' or
> 'replace' method which would make them destructively update their
> value.
I played around with adding a method Module#become(other) (IIRC)
that would cause an object to replace itself with another; the intended
use was a distribution/persistence layer that could invisibly swap
objects out and replace them with stubs that would then bring back the
original object on access.
Again, if I recall correctly, I got it to the sort-of-working
stage, but bogged down in dealing with the details of some of the
built-in classes, singletons, etc.
-- MarkusQ
Lennon Day-Reynolds
Array, and Hash all implement...I really should just assume that the
standard library already does anything clever I can think of.
--
Lennon
rcoder.net
Brian Wisti
--- Nate Smith <nsm...@nist.gov> wrote:
> Try
>
> print "a" + 1
>
> Won't work -- you have to do
>
> print "a" + 1.to_s
>
>
> Nate
That "+" means you're building a new string from two Strings. Since the
second operand is not a String, the conversion has to be explicit.
Now, for simple printing, it just occurred to me to test what happens
when you hand a printf-style expression to print, as I might do in the
same situation with Python:
irb > print "a%d" % 1
a1 => nil
So, that's One Way To Do It.
-- Brian Wisti
http://coolnamehere.com/
David A. Black
On Fri, 17 Sep 2004, Brian Wisti wrote:
>
> --- Nate Smith <nsm...@nist.gov> wrote:
>
> > Try
> >
> > print "a" + 1
> >
> > Won't work -- you have to do
> >
> > print "a" + 1.to_s
> >
> >
> > Nate
>
> That "+" means you're building a new string from two Strings. Since the
> second operand is not a String, the conversion has to be explicit.
If the second operand responds to to_str, then its response to to_str
will be used in cases where only a string will do:
irb(main):016:0> obj = Object.new
=> #<Object:0x402a6e94>
irb(main):017:0> puts "this is an " + obj
TypeError: cannot convert Object into String
from (irb):17:in `+'
from (irb):17
from :0
irb(main):018:0> def obj.to_str; "implicit string representation!";
end
=> nil
irb(main):019:0> puts "this is an " + obj
this is an implicit string representation!
Brian Wisti
So we just have Fixnums and similar types not responding to to_s?
Interesting...
-- Brian Wisti
David A. Black
> So we just have Fixnums and similar types not responding to to_s?
> Interesting...
No, they do respond to to_s, but not to to_str. It's to_str that
provides this kind of masquerading facility.
Robert Klemme
"Karl von Laudermann" <dood...@mailinator.com> schrieb im Newsbeitrag
news:729e3289.0409...@posting.google.com...
> "Robert Klemme" <bob....@gmx.net> wrote in message
news:<2qsugrF...@uni-berlin.de>...
> > "James Edward Gray II" <ja...@grayproductions.net> schrieb im
Newsbeitrag
> > news:CBB35FB8-0732-11D9...@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.
Others might think different about this - I do for example. :-) You
simply enumarate things to get printed. Also, it's more efficient to
individually print items than to first concatenate them (creates new temp
instances) and then print that temp String instance. If I have more
complex printouts I use String interpolation with "#{}" or printf anyway.
> 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.
It's perfectly logical because these are two completely unlelated things:
String#+ is something different than the behavior of Kernel#print.
> Perhaps
> String#+ should be modified to call to_s on its arguments?
It is done deliberately the way it is: String#+ is "intelligent" enough to
invoke #to_str on its arguments; but an instance that has no #to_str
cannot be "legally" concatenated with a String.
>> class Foo; def to_str; "xxx" end end
=> nil
>> Foo.new
=> #<Foo:0x10187990>
>> Foo.new.to_str
=> "xxx"
>> puts "2" + Foo.new
2xxx
=> nil
> 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.
Well, you can use puts with interpolation or define a println method if
you really care to save the "\n" typing effort:
module Kernel
private
def println(*args) print *args << "\n" end
def smart_println(*args)
args << "\n" unless /\n$/ =~ args[-1].to_s
print *args
end
end
Kind regards
robert
Nate Smith
> On Thu, 2004-09-16 at 10:28, Nate Smith wrote:
>
> > Is there any way to change an outside-scoped object inside a proc? Such
> > as:
> Why do you think this is needed (or nice) for writing a collect!
> method? Why cant you just write something like:
>
> class My_collection_class
> def [](k)
> :
> end
> def []=(k,v)
> :
> end
> def each_key
> :
> end
> def collect!
> each_key { |k| self[k] = yield(self[k]) }
> end
> end
Very true indeed (that works great). I was more thinking about
collecting for the key and the value in one swoop, but that may be more
trouble than it's worth.
Nate