Forum: Ruby A crosspost from the Perl Community

All,

I've been thinking of myself as a Perl developer for the past several
years, and recently was handed a Ruby project. I collected some of my
thoughts on the experience for PerlMonks, and it was suggested that I
cross post in a Ruby forum to see what sorts of responses the other half
might have to offer.

Seeing as how I found Ruby to be a good language that I anticipate using
in the future, I think it's a good idea, and so I offer it below:

------

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

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

--What a Dump!--

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

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

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

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

--OOPs and Infrastructure--

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

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

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

_Perl Code_
foreach my $member @array { ... }

rather than

_Ruby Code_
array.each { ... }

Then again, that's a habit that one learns to change. Which brings me to
the next item.

--The Variable Appearance of Variables--

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

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

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

--Testing and Documentation.--

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

--Community Support--

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

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

--Conclusions--

Ruby is an excellent language, and I'm interested/eager to learn more
about it. With a variety of Ruby related modules on CPAN,
interoperability between the two languages doesn't appear to be out of
the question. It seems to me that Ruby will make a better choice for OOP
when it's called for, and can be an excellent way of rapid prototyping
class hierarchies before developing them in another OO language.
<P>
That said, I've always believed that the strength of any organization is
in its people. Perl provides the model of a development community that
other languages strive for, and as a result, when I'm presented with a
task that seems unusual, awkward, or that requires fitting the square
peg in the triangular hole, Perl will continue to be the natural choice.

--Further Reading--
 * http://use.perl.org/~jmcada/journal/32457
 * Thomas, Dave. "Programming Ruby, The Pragmatic Programmers' Guide."
Pragmatic Programmers, LLC. Raleigh, 2005.
 * Introduction to Ruby for Perl Programmers

Originally posted on PerlMonks at http://perlmonks.org/?node_id=689996

On Wednesday 04 June 2008 12:20:37 Star Cross wrote:

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

Very true. But can you make Perl as pretty as Ruby?

Every language can be made messy. Not every language can be made clean.

> Perl programmers have got used to being able to tell what they're
> looking at at a glance. $scalar, @array, %hash are all great ways of
> being able to figure out what sort of data you're working with at the
> moment.

Until you start working with objects. Then everything's a scalar:

$myobject->{some_value}
$myobject->method_a()->method_b()

At this point, the only advantage of $ is that it's easier to tell that 
this
is a variable, and not a command. This distinction isn't as useful in 
Ruby, I
think, because of how easy it is to use accessors -- at which point, you
don't need to know if it's a variable or a method.

> Ruby doesn't use this convention, and boy did I miss it. The @ character
> makes an appearance to signify a class variable, but that's it.

Actually, there's also $ for globals, and captialization for Constants.

> The fact 
> that hashes and arrays are both indexed using square brackets ([])
> contributes to the confusion.

In Perl, I often fell into the trap of naming several variables the same
way -- I would have two or more of:

@foo
$foo
%foo

So, while it's not quite as concise, if there's ever confusion, I will 
name
things appropriately.

There's also the fact that I can't remember the last time I accessed an 
array
with the [] notation. Most often, it's through things like <<, each (and
other iterators like inject), and +.

While I'm at it, one thing I do miss from Perl is variable declarations 
being
enforced with 'use strict' -- in Ruby, the lack of this means that
misspelling a variable name could lead to a much subtler error than 
"requires
explicit package name".

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

It's worth mentioning that their respective infrastructures (rubygems vs 
CPAN)
are at least comparable, technically. As far as I know, Python's 
equivalent
isn't.

And it's not often these days that I can't find something I need as a 
gem, and
it exists as a CPAN module. Maybe that reflects my own inexperience, 
though.

It's also a fundamentally different community, I think -- it exists 
largely in
blogs. When I had a question about how to do something in Perl, I'd most
often look on CPAN and find it already done, with good examples in the
documentation. When I have a question about how to do something in Ruby, 
I
use Google, and almost always land on someone's blog.

Good post, though. I, too, knew Perl long before I knew Ruby, and I 
drift back
and forth over time.

> No looking back to see if c was declared as an int, a char, or a
> float. Easier to keep track of what you and other people are doing.

Yeah some people consider it a 'feature' that you don't know what you're 
dealing with, only that it quacks like a duck.  One thing you can do 
[and no one does] is name your variables, like i_count i_number.
I'll just go ahead and say it, though.  when I look back at perl code 
the first that strikes me is that it hurts my eyes to see all those $'s.

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

Yeah Ruby just doesn't seem to have tons and tons of community.  Not 
yet, at least.  Ex: developing core things, like the GC, or porting 
things to mingw.  If you ever want to feel alone...
That being said for normal ruby stuff there's not tons of support but 
you CAN just hack what exists and come up with acceptable solutions, and 
submit a patch [and it usually doesn't hurt too bad].  Now that is nice. 
Probably also possible in perl.  So they're similar :)
-R

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roger Pack wrote:
|> No looking back to see if c was declared as an int, a char, or a
|> float. Easier to keep track of what you and other people are doing.
|
| Yeah some people consider it a 'feature' that you don't know what you're
| dealing with, only that it quacks like a duck.  One thing you can do
| [and no one does] is name your variables, like i_count i_number.

int[] numbers; //straight from MS's C# tutorial on Arrays
byte[] number; // Contrived example on my part.

Do you remember that numbers is an array of integers 10 LOC later? What
about 100 LOC? Do you remember that number is an Array of bytes?

The issue you describe is not an issue of a broken tool or feature. But
a lack of naming conventions, as you said.

Oh, and in your example: does 'i' signify 'integer' or 'input'? ;)

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com

~   It seems like once people grow up, they have no idea what's cool.
      -- Calvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhG+fsACgkQbtAgaoJTgL8lOACfSaEF1i79PG+cFT2HFCgY4w2h
etYAnjQ6mOjEyI6wylTlpvVzCJJAZifP
=aKhH
-----END PGP SIGNATURE-----

On 04.06.2008 19:20, Star Cross wrote:

> I've been thinking of myself as a Perl developer for the past several
> years, and recently was handed a Ruby project. I collected some of my
> thoughts on the experience for PerlMonks, and it was suggested that I
> cross post in a Ruby forum to see what sorts of responses the other half
> might have to offer.
> 
> Seeing as how I found Ruby to be a good language that I anticipate using
> in the future, I think it's a good idea, and so I offer it below:

Thank you for sharing this!

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

I will try to comment in that very spirit because you triggered some
interesting thoughts about the two languages.

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

I find a poorly indented application hard to read in *every* programming
language.

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

I am not sure I get your point here: if _statement_ separators are not
used they do not clutter.  How does this *option* remove the benefit of
readability?

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

Well, you can probably do this with every language. :-)

> From this Perl programmer's perspective, it takes some getting used to.
> Instinctively one wants to write
> 
> _Perl Code_
> foreach my $member @array { ... }
> 
> rather than
> 
> _Ruby Code_
> array.each { ... }

If you like you can as well do

for member in array
   ...
end

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

My Perl has become a bit rusty over the years with Ruby but I tend to
find it difficult to find my way through $, ->, % and combinations of
those if I look at a Perl program these days.  I definitively feel more
comfortable with the Ruby way which is probably also a matter of what
you are used to.  Maybe you could put it this way:

A Ruby programmer is more interested in what is done with an object (aka
which methods are invoked) whereas a Perl programmer is more focussed on
the type of data.  (Digressing a bit here to a topic that may be
related: I have the impression that when writing Perl programs people
usually use nested structures of arrays, hashes and scalars to represent
complex data whereas in Ruby land people - at least I - tend to rather
create classes and use them because it is so much easier than in Perl.
This gives you the additional benefit of encapsulating methods with the
data whereas in Perl you have to write functions for this type of data
structure.  For me the Ruby way is easier and also easier to maintain,
but then again I might not have been a good Perl programmer.)

Also, if you write OO programs this distinction goes away in Perl as
well IIRC.

> Ruby doesn't use this convention, and boy did I miss it. The @ character
> makes an appearance to signify a class variable, but that's it.

@ signifies an instance variable, whereas class variables are prefixed
with @@ (but rather not use them as their scoping is a bit weird and can
easily lead to strange bugs).  If a @variable is a member of a class
then it is sometimes also called "class variable" although I believe the
more appropriate term would be "class instance variable".  Then we also
$global_variables.

> The fact
> that hashes and arrays are both indexed using square brackets ([])
> contributes to the confusion. It's good that these elements are present,
> but it's a potential pitfall, and again, it takes some getting used to.

I have the impression that in the Ruby community this is rather seen as
an advantage (-> duck typing).  In other words you can exchange a Hash
or anything else that supports #[] for an Array easily.  So there are
definitively two sides to this coin.

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

That may be true on the statement level, but I find it easier to
identify the structure of a Ruby program.

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

Just for the sake of completeness: there is also RAA although it is
probably not as complete as CPAN.
http://raa.ruby-lang.org/

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

There is at least a very active (and friendly) community accessible
through web forum, mailing list and usenet.  Often answers come pretty
fast, too.  As far as I can see from the PerlMonks FAQ(*) ruby-talk
serves the same purpose although I cannot reasonably compare them as I
have 0 knowledge of PM.

* http://perlmonks.org/?node_id=243870

> --Conclusions--
> 
> Ruby is an excellent language, and I'm interested/eager to learn more
> about it. With a variety of Ruby related modules on CPAN,
> interoperability between the two languages doesn't appear to be out of
> the question.

I did not know that.  Actually I cannot remember that the topic of
integrating Perl and Ruby came up on ruby-talk; it's probably very
infrequent.

> It seems to me that Ruby will make a better choice for OOP
> when it's called for, and can be an excellent way of rapid prototyping
> class hierarchies before developing them in another OO language.

Absolutely agree.

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

My mileage varies but I guess that is just a matter of personal taste
and experience.

However, there is one thing that you did not mention and that can be
said in favor of Perl because it sometimes matters: runtime performance
of Perl programs is often better than that of Ruby programs.

Kind regards

  robert

On Wed, Jun 4, 2008 at 10:00 PM, Roger Pack <rogerpack2005@gmail.com> 
wrote:
> I'll just go ahead and say it, though.  when I look back at perl code
> the first that strikes me is that it hurts my eyes to see all those $'s.

The funny thing is that this was my feeling about ruby back when I was
a python guy.
I heard that it's a nice language, but anytime I saw those @ and $ I
turned back.

Apparently that time I preferred self and __init__ to @s and $s. Now
it's the other way round.

J.

Star Cross wrote:
(...) and as a result, when I'm presented with a
> task that seems unusual, awkward, or that requires fitting fitting the square
peg in the triangular hole, Perl will continue to be the natural choice.
> 
> 
> Originally posted on PerlMonks at http://perlmonks.org/?node_id=689996

I learnt both languages more or less simultaneously. Learning ruby meant 
(re)thinking OO, learning Perl meant learning syntax. Ruby's syntax 
suits me far better. In Perl, I never get it right the first time (nor 
the second time); in ruby sometimes dozens of LOC will just run.
On the other hand, the few times I used some of Perl's CPAN modules, I 
found they are indeed well designed, well documented and a breeze to 
use.

So, if a triangular peg in needs to be put in a triangular hole, I'll 
happily resort to Perl if I can't get it to work with ruby.
If a square peg needs to be put in a triangular hole however, I prefer 
ruby (and a hammer).

regards,

Siep

"Star Cross" <starx@axisoftime.com> wrote in message
news:35db1cb396d98e77362722b737b4ccf5@ruby-forum.com...
> All,
>
> I've been thinking of myself as a Perl developer for the past several
> years, and recently was handed a Ruby project. I collected some of my
> thoughts on the experience for PerlMonks, and it was suggested that I
> cross post in a Ruby forum to see what sorts of responses the other half
> might have to offer.
>
> Seeing as how I found Ruby to be a good language that I anticipate using
> in the future, I think it's a good idea, and so I offer it below:
[ SNIP ]
> for example, is an instance of the Array object, and contains useful
> methods for working with the array; iterators, for example. Hashes work
> similarly.
[ SNIP ]

Good post. I too am Perl first, having started with Perl 4 back in the 
early
'90's. Perl really set the tone for infrastructure - you mention CPAN, 
but
POD and the classic mechanics of Perl modules also stand out.

I'd agree with you, having started to use Ruby some in this past year or 
so.
For OOP I think I'd go with Ruby. Interestingly enough I do not believe 
I
would have adopted this viewpoint until having used "clean" OOP 
languages
like Java or C#...Perl 5 was my second OOP language after C++ (well, 
really
the third if one considers Prograph), and so after C++ I certainly 
didn't
think of Perl OOP as being particularly cumbersome. :-)

For most scripts I'd still use Perl. A matter of familiarity more than
anything else.

AHS

Coming to Ruby recently from Perl, these are my comments.

Star Cross wrote:
> Ruby seems to escape this criticism, and yet it can be every bit as
> ugly. A lack of curly braces around definitions takes some getting used
> to, and it makes a poorly indented application hard to read at a glance.
> 
> Another big departure was in the lack of line separators (;), or perhaps
> I should instead say that they're *optional*.

All languages are different. You soon get used to it! From someone who 
cut his teeth on Fortran IV, Ruby's layout doesn't look too bad.

> Ruby, on the other hand, is OO from the ground up, making it more
> friendly to the Java trained OO programmer. Or at least to this one.
> Ruby takes it a step further though, and does away with primitive types,

Ruby is much more OO than Perl. I started with Perl 4.036, which had no 
objects, then Perl 5 really had OO kludged onto it in a nasty way. In 
Ruby, everything is OO. (This is much nicer than Java, which I've also 
used.)

> Perl programmers have got used to being able to tell what they're
> looking at at a glance. $scalar, @array, %hash are all great ways of
> being able to figure out what sort of data you're working with at the
> moment.

Ruby has a different model. In Ruby, variables are *references* to 
objects. So an array variable is the same as a hash variable etc: 
they're all just references to objects. In Perl, references are all $ 
variables, so it's no different really. (One can easily devise a naming 
system to help you remember what everything is, if necessary.)

You can get bitten by this. Everything is call-by-reference, not 
call-by-value as in Perl, C etc. Change a function's parameter and you 
change the original, not a local copy of it.

> The fact
> that hashes and arrays are both indexed using square brackets ([])
> contributes to the confusion.

No, they're both arrays; it's just a question of whether they're ordered 
and indexed by integers (like Perl arrays), or unordered and indexed by 
whatever you like (like Perl hashes). The square brackets consistently 
denote indexing.

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

I find the contrary. Uncommented Perl is typically impossible to 
understand unless you wrote it yourself. It *is* possible to write clear 
Perl but, as with C, most people don't bother.

> Ruby has test/unit. 

Much much better than anything I've used in Perl. Test/unit makes 
test-driven development a breeze. Best thing since sliced bread!

> That said, I've always believed that the strength of any organization is
> in its people.

It's the language I'm interested in, not the people. That's why I went 
into engineering rather than social work or politics!  ;-)

On Thu, Jun 5, 2008 at 10:00 AM, Dave Bass <davebass@musician.org> 
wrote:
> You can get bitten by this. Everything is call-by-reference, not
> call-by-value as in Perl, C etc. Change a function's parameter and you
> change the original, not a local copy of it.

No, ruby is still call-by-value.  The "value" is an object reference
(or simply an object in ruby terms).   If the object is mutable, then
a function can modify it.  Call-by-reference on the other hand refers
to passing an lvalue reference.  If ruby had call-by-reference, you
could pass an lvalue (something that can be on the left side of an
assignment) and when the function modified the corresponding argument
variable, the lvalue would change (not just the object that the lvalue
has).

Perl actually does have call by reference.  The items in @_ for a sub
can be lvalue references and changing them changes the callers lvalue.
 But, most start a perl sub with something like this copies that
values (losing the references):

my($a, $b) = @_;

C++ can also call-by-reference and C can emulate it (with pointers to 
lvalues).

With a bit of work you can also emulate call-by-reference in Ruby.
Here's an example using simple lambdas:

def swap(get0, set0, get1, set1)
    tmp = get0
    set0[get1]
    set1[tmp]
end

a = 1
b = 2

swap(lambda{a}, lambda{|v| a=v}, lambda{b}, lambda{|v| b=v})

On Jun 4, 2008, at 10:20 AM, Star Cross wrote:

> array.each { ... }
I no longer think this way about programs I write.  Enumerable and
block argument multiple assignment allow you to not care about what
type of object is on the left hand side.  Instead you can use friendly
variable names to make your code very readable.

An arbitrary example would be:

meetings = {
   'eric' => ['thursday at 1100', '206-555-0000']
   'ryan' => ['thursday at 1300', '206-555-0001']
}

meetings.each do |callee, (time, phone_number)|
   puts "call #{callee} at #{time} on #{phone_number}"
end

Eric Mahurin wrote:
> No, ruby is still call-by-value.  The "value" is an object reference
> (or simply an object in ruby terms).

So you pass a reference to a function. Isn't this call-by-reference???

Whatever the technicalities, what I mean is this. In Perl:

  sub upper
  {
    my $x = shift;
    $x =~ tr/a-z/A-Z/;
  }

  $a = "hello";
  upper($a);
  print $a;  # => "hello"

$a is unchanged because $x is a local copy of $a; changing $x leaves $a 
unchanged. But in Ruby:

  def upper(x)
    x.upcase!
  end

  a = "hello"
  upper(a)
  print a  # => "HELLO"

The original a is changed because upper has direct access to it. You can 
get the same effect in Perl using explicit referencing and 
dereferencing:

  sub upper
  {
    my $x = shift;
    $$x =~ tr/a-z/A-Z/;
  }

  $a = "hello";
  upper(\$a);
  print $a;  # => "HELLO"

Dave

Dave Bass wrote:

> Eric Mahurin wrote:
>> No, ruby is still call-by-value.  The "value" is an object reference
>> (or simply an object in ruby terms).
> 
> So you pass a reference to a function. Isn't this call-by-reference???
[ SNIP ]

No, because you can pass a reference by value _or_ by reference. The
difference is basically this: if an argument is a reference, and it's
pass-by-value, the method has a _copy_ of the reference...you can use 
that
to make changes to the referenced object. But you cannot change - in the
method - what the reference points to in the calling code.

If you pass a reference by reference, you can make a change in the 
method to
what the reference points to, and the calling code will see this change.

It's not a fine distinction. It's why you cannot write a canonical 
object
swap function (using a temp variable) in Java, but can in C++.

AHS

On Fri, Jun 6, 2008 at 6:31 AM, Dave Bass <davebass@musician.org> wrote:
> Eric Mahurin wrote:
>> No, ruby is still call-by-value.  The "value" is an object reference
>> (or simply an object in ruby terms).
>
> So you pass a reference to a function. Isn't this call-by-reference???

The traditional "reference" in "call-by-reference" is an lvalue 
reference.

>  print $a;  # => "hello"
>
> $a is unchanged because $x is a local copy of $a; changing $x leaves $a
> unchanged.

perl actually is call-by-reference.  $x is a local copy, but $_[0] is
an lvalue reference to $a.  Try this:

 sub upper { $_[0]=~ tr/a-z/A-Z/; }

 $a = "hello";
 upper($a);
 print $a;  # => "HELLO"

sub swap {@_[0..1] = ($_[1], $_[0])}
$a = 1; $b = 2;
swap($a, $b);
print("$a $b\n"); # => "2 1"

But in Ruby:
>
>  def upper(x)
>    x.upcase!
>  end
>
>  a = "hello"
>  upper(a)
>  print a  # => "HELLO"
>
> The original a is changed because upper has direct access to it.

upper didn't change the variable "a" (the lvalue).  It still has the
same object it had before it called upper.  upper did change the
object that "a" had though.

Compare to:

def swap(a, b)
 a,b = b,a
end
a = 1
b = 2
swap(a, b)
print("#{a} #{b}\n") # => "1 2"

>  $a = "hello";
>  upper(\$a);
>  print $a;  # => "HELLO"

Yep.  Ruby's objects are equivalent to Perl's references.  When you
say this is ruby:

a = "hello"

it is equivalent to this in Perl:

$a = \"hello"

In ruby, I sometimes miss the ability to easily reference and
dereference lvalues.  There is always another way, but having lvalue
references/pointers would sometimes be more elegant.

2008/6/6 Eric Mahurin <eric.mahurin@gmail.com>:
> In ruby, I sometimes miss the ability to easily reference and
> dereference lvalues.  There is always another way, but having lvalue
> references/pointers would sometimes be more elegant.

Can you give an example?  I'm curios because I never missed this and
I'd like to know what I am overlooking.  It may be that my mindset is
so Java / Ruby already that I simply do not think in ways that would
make references useful - or I deal with a different class of problems
which can be more easily solved without.

Kind regards

robert

On Fri, Jun 6, 2008 at 7:29 AM, Robert Klemme
<shortcutter@googlemail.com> wrote:
> 2008/6/6 Eric Mahurin <eric.mahurin@gmail.com>:
>> In ruby, I sometimes miss the ability to easily reference and
>> dereference lvalues.  There is always another way, but having lvalue
>> references/pointers would sometimes be more elegant.
>
> Can you give an example?  I'm curios because I never missed this and
> I'd like to know what I am overlooking.  It may be that my mindset is
> so Java / Ruby already that I simply do not think in ways that would
> make references useful - or I deal with a different class of problems
> which can be more easily solved without.

A general category would be data structures of a linked set of nodes -
trees (i.e. AVL, red-black, splay, B), linked lists (single, double),
graph, etc.  Each node can be easily represented in Ruby with an
object that has one or more instance variables for the "links" where
each link holds another node or nil.  Many operations may equally
apply to the head/root of the data structure or somewhere in the
middle (a sub head/root).  Not a problem for Ruby as long as this
operation doesn't want to modify the link at that point.  In other
languages we might pass a reference/pointer of the variable with the
link so that it could be modified.  In Ruby, you'll have come up with
another solution: a) pass the node containing the link you want to
operate along with something saying which link in the node (you'll
probably also need a dummy node at the root/head), b) have a separate
object for the link so you can pass it around (i.e. simply an Array of
one element), c) pass a lambda that can modify the link.  None of
these are as elegant as an lvalue reference IMHO.  In my early ruby
days a few years ago I put some code in the rubyforge "reference"
project.  I still think having something like this readily available
would be useful.

External iterators are also like lvalue references and is something
ruby is missing (IMHO).  An external iterator could be thought of as a
superset of the reference/pointer concept (external iterator looks
like a pointer in C++).

Both (lvalue) references/pointers and external iterators could be
implemented with normal ruby classes and methods (in ruby or more
efficiently in C).

Eric

On 06.06.2008 17:01, Eric Mahurin wrote:
>> which can be more easily solved without.
> link so that it could be modified.  In Ruby, you'll have come up with
> another solution: a) pass the node containing the link you want to
> operate along with something saying which link in the node (you'll
> probably also need a dummy node at the root/head), b) have a separate
> object for the link so you can pass it around (i.e. simply an Array of
> one element), c) pass a lambda that can modify the link.  None of
> these are as elegant as an lvalue reference IMHO.  In my early ruby
> days a few years ago I put some code in the rubyforge "reference"
> project.  I still think having something like this readily available
> would be useful.

The usual solution in Ruby would probably be a) which I find perfectly
ok.  Since the manipulation is typically encapsulated inside a
LinkedList class it does not bother me too much if there are two
additional elements (for head and tail). :-)  But I can see how this
might be a bit more elegant with references (although not as much to
create an urgent need for references in Ruby). :-)

> External iterators are also like lvalue references and is something
> ruby is missing (IMHO). 

Is it?

irb(main):027:0> require 'generator'
=> true
irb(main):028:0> arr = %w{foo bar baz}
=> ["foo", "bar", "baz"]
irb(main):029:0> it = Generator.new arr
=> #<Generator:0x1002ffe8 @cont_endp=nil, @index=0,
@block=#<Proc:0x1001bbc4@/usr/lib/ruby/1.8/generator.rb:71>,
@cont_yield=#<Continuation:0x1002f5fc>, @cont_next=nil, @queue=["foo"]>
irb(main):030:0> until it.end?; puts it.current; it.next; end
foo
bar
baz
=> nil

> An external iterator could be thought of as a
> superset of the reference/pointer concept (external iterator looks
> like a pointer in C++).

Which is nicely done (in C++'s STL, I mean).  But with blocks I don't
really miss external iterators.  I rarely have to iterate through
multiple collections in lock step and if I had #zip served me well.

Maybe I'm just not doing enough development that involves sophisticated
algorithms. :-)

Thanks for your explanation!

Kind regards

  robert

On Friday 06 June 2008 06:31:59 Dave Bass wrote:
>   def upper(x)
>     x.upcase!
>   end

It depends very much what your intent was -- upcase without the bang 
will
return an upcase'd version, leaving the original untouched. A closer 
version
to your Perl example might be:

def upper(x)
  x = x.upcase
end

The original string is untouched, but the reference 'x' now points to 
the
result of that upcase.

Given that a lot of Ruby methods follow that convention, it feels like
pass-by-value, and performs like pass-by-reference. (In theory; I guess 
we'll
have to wait for 1.9 for real performance.)

> The original a is changed because upper has direct access to it.

Well, and because a method was called on it. A contrived, untested Perl
example:

package String;
sub new {
  my $class = shift;
  my $self = {string => shift};
  bless $self => $class;
}

sub upcase {
  my $self = shift;
  $self->{string} =~ tr/a-z/A-Z/;
}

sub upper {
  my $x = shift;
  $x->upcase();
}

my $string = String->new('hello');
upper($string);

At this point, $string should have a member value of 'HELLO'.

In other words: Perl, like Ruby, represents objects as references. The 
only
difference is, in Ruby, all values are objects. In Perl, there's a set 
of
primitive values -- strings, numbers, arrays, and hashes -- which are 
not
objects.

(Maybe they are with some deep voodoo like ties, but I never got that 
deep in
Perl.)

David Masover wrote:
> On Wednesday 04 June 2008 12:20:37 Star Cross wrote:
> 
>> Lesson: You can make Ruby every bit as messy as Perl if you want to.
> 
> Very true. But can you make Perl as pretty as Ruby?

BS. Not unexpected. Besides beauty is in the eye of the beerholder, 
cleanliness likewise.

> Every language can be made messy. Not every language can be made clean.

Agreed. For example with the meaningful newlines there are cases when 
you can't make the Ruby code clean, because you either can't break the 
overly long line or you can, but you end up with an operator lost on the 
far right or with some silly line continuation character.

Robert Klemme (Guest) on 04.06.2008 23:00 wrote:
> I have the impression that when writing Perl programs people usually 
> use nested structures of arrays, hashes and scalars to represent
> complex data whereas in Ruby land people - at least I - tend to rather
> create classes and use them because it is so much easier than in Perl.

Or could it be that using the nested structures is harder in Ruby? 
Oftentimes the classes are simple to make but do they give you anything? 
You should not be creating classes just because it's easy to do so. You 
should create them because it gives you something.

Dave Bass (dogsbody) on 05.06.2008 17:01 wrote:
> I find the contrary. Uncommented Perl is typically impossible to 
> understand unless you wrote it yourself. It *is* possible to write 
> clear Perl but, as with C, most people don't bother.

Uncommented hungarian is impossible to understand as well ... unless you 
actually know that language. Or maybe you were talking about golf or 
yaph or poetry?

Jenda

Does Star Cross reply?

Seems a bit lost in all this. A heavy perl user that praises perl 
including it's disadvantages... perl is readable?

Yeah. For C fossil coders maybe. 8)

Let's challenge the perl folks. They claim that perl is more readable 
than ruby?

Let's make a rubyquiz-perlquiz challenge.

We need to solve something, the perl guys do it.

Then we compare our solutions. (Only "in-built" stuff is allowed, i.e. 
no cpan modules rubygems etc... things would have to be used from 
scratch, so that no language gains an inherent advantage over the other)

> BS. Not unexpected. Besides beauty is in the eye of the beerholder, 
> cleanliness likewise.

Somewhat of an inflammatory response.
Guess there are perl lovers out there still :)
-R

> We need to solve something, the perl guys do it.

Oh, something was lost. I actually meant we BOTH (ruby folks, and perl 
folks)
need to solve a (or several) specific problem(s).

Then we can see which language is cleaner.

Marc Heiler wrote:
>> We need to solve something, the perl guys do it.
> 
> Oh, something was lost. I actually meant we BOTH (ruby folks, and perl 
> folks)
> need to solve a (or several) specific problem(s).
> 
> Then we can see which language is cleaner.

Who's gonna be the judge? Besides, define cleaner!

No matter the solutions, the Ruby ones will look cleaner to the Ruby 
proponents and the Perl one to the Perl ones. There's nothing to be 
gained from this exercise.

Jenda

On Fri, Jun 6, 2008 at 1:27 PM, Jenda Krynicky <jenda@cpan.org> wrote:
> Who's gonna be the judge? Besides, define cleaner!
>
> No matter the solutions, the Ruby ones will look cleaner to the Ruby
> proponents and the Perl one to the Perl ones. There's nothing to be
> gained from this exercise.

You would need a third party.

Todd

Todd Benson wrote:
> On Fri, Jun 6, 2008 at 1:27 PM, Jenda Krynicky <jenda@cpan.org> wrote:
>> Who's gonna be the judge? Besides, define cleaner!
>>
>> No matter the solutions, the Ruby ones will look cleaner to the Ruby
>> proponents and the Perl one to the Perl ones. There's nothing to be
>> gained from this exercise.
> 
> You would need a third party.
> 
> Todd

Someone who doesn't know either language? Which would not help much 
'cause that someone needs to know at least some other programming 
language to have any idea whatsoever what's going on in here and then 
which ever's closer to his/her language wins.

Spanish makes more sense that English to a portuguese that doesn't know 
either, does it say anything about the relative complexity of the two 
languages?

Beauty contests are a nice pretext for watching a few chicks in swimwear 
(or wet tshirts), but it's not a way to find the most beautiful girl of 
the USA in the year 2008. Cause there is no such thing.

Jenda

On Fri, Jun 6, 2008 at 10:49 AM, Robert Klemme
<shortcutter@googlemail.com> wrote:
>
> The usual solution in Ruby would probably be a) which I find perfectly ok.
>  Since the manipulation is typically encapsulated inside a LinkedList class
> it does not bother me too much if there are two additional elements (for
> head and tail). :-)  But I can see how this might be a bit more elegant with
> references (although not as much to create an urgent need for references in
> Ruby). :-)

Definitely no urgent need, but a nice thing to have in a bag of
tricks.  It could be implemented in Ruby, but you'll get more
efficiency if done in C (ruby implementation would typically need eval
- at least for local vars).  No special syntax needed.

> => #<Generator:0x1002ffe8 @cont_endp=nil, @index=0,
> @block=#<Proc:0x1001bbc4@/usr/lib/ruby/1.8/generator.rb:71>,
> @cont_yield=#<Continuation:0x1002f5fc>, @cont_next=nil, @queue=["foo"]>
> irb(main):030:0> until it.end?; puts it.current; it.next; end
> foo
> bar
> baz
> => nil

This just gives a very limited external iterator that can read and
move forward (just like an internal iterator).  In C++ terms, this
corresponds to one of the simplest - "Input Iterator".  Other
operations you might want to do where the iterator is at would be:
write, move back, insert, delete, random access.

>> An external iterator could be thought of as a
>> superset of the reference/pointer concept (external iterator looks
>> like a pointer in C++).
>
> Which is nicely done (in C++'s STL, I mean).  But with blocks I don't really
> miss external iterators.  I rarely have to iterate through multiple
> collections in lock step and if I had #zip served me well.

#zip doesn't help if you want to write, back-up, insert, delete, etc
during iteration.

> Maybe I'm just not doing enough development that involves sophisticated
> algorithms. :-)

Well, the last year or so I've been exposed to quite a bit of
computational geometry and graph theory.  Most of that has been in C++
and a bit of Python (would have used Ruby, but needed a certain API).
Outside of that, my experience would say the same as you.  Usually
simple data structures and access methods suffice.

Eric

On 07.06.2008 04:30, Eric Mahurin wrote:
>>> project.  I still think having something like this readily available
> efficiency if done in C (ruby implementation would typically need eval
> - at least for local vars).  No special syntax needed.

Acutally, there *is* an implementation already:

irb(main):002:0> s=SimpleDelegator.new nil
=> nil
irb(main):003:0> s.__getobj__
=> nil
irb(main):004:0> s.__setobj__ "foo"
=> "foo"
irb(main):005:0> s
=> "foo"
irb(main):006:0> s.__getobj__
=> "foo"
irb(main):007:0> s.__setobj__ "bar"
=> "bar"
irb(main):008:0> s.__getobj__
=> "bar"
irb(main):009:0> s.length
=> 3
irb(main):010:0> s.gsub /./, 'X'
=> "XXX"

:-)

>>> External iterators are also like lvalue references and is something
>>> ruby is missing (IMHO).
>> Is it?
>>
>> irb(main):027:0> require 'generator'

> This just gives a very limited external iterator that can read and
> move forward (just like an internal iterator).  In C++ terms, this
> corresponds to one of the simplest - "Input Iterator".  Other
> operations you might want to do where the iterator is at would be:
> write, move back, insert, delete, random access.

Right you are.

>>> An external iterator could be thought of as a
>>> superset of the reference/pointer concept (external iterator looks
>>> like a pointer in C++).
>> Which is nicely done (in C++'s STL, I mean).  But with blocks I don't really
>> miss external iterators.  I rarely have to iterate through multiple
>> collections in lock step and if I had #zip served me well.
> 
> #zip doesn't help if you want to write, back-up, insert, delete, etc
> during iteration.

Correct.  For Array this could easily be build as an external class
(attached is an experimental version).

>> Maybe I'm just not doing enough development that involves sophisticated
>> algorithms. :-)
> 
> Well, the last year or so I've been exposed to quite a bit of
> computational geometry and graph theory.  Most of that has been in C++
> and a bit of Python (would have used Ruby, but needed a certain API).
> Outside of that, my experience would say the same as you.  Usually
> simple data structures and access methods suffice.

Thank you for this exchange!

Kind regards

  robert

On 6/7/08, Robert Klemme <shortcutter@googlemail.com> wrote:
> On 07.06.2008 04:30, Eric Mahurin wrote:
>
> > On Fri, Jun 6, 2008 at 10:49 AM, Robert Klemme
> > <shortcutter@googlemail.com> wrote:
> >
> > > On 06.06.2008 17:01, Eric Mahurin wrote:
> > >
> > > > another solution: a) pass the node containing the link you want to
> > > > operate along with something saying which link in the node (you'll
> > > > probably also need a dummy node at the root/head), b) have a
separate
> > > > object for the link so you can pass it around (i.e. simply an Array
of
> > > it does not bother me too much if there are two additional elements
(for
> > > head and tail). :-)  But I can see how this might be a bit more
elegant
> with
> > > references (although not as much to create an urgent need for
references
>  Acutally, there *is* an implementation already:
>  => "foo"
>  irb(main):007:0> s.__setobj__ "bar"
>  => "bar"
>  irb(main):008:0> s.__getobj__
>  => "bar"
>  irb(main):009:0> s.length
>  => 3
>  irb(main):010:0> s.gsub /./, 'X'
>  => "XXX"
>
>  :-)


But, this doesn't give you an lvalue reference, just an anonymous 
reference
(which could be used for a case b implementation).  A one element Array
would work just as well:

s = ["foo"]
p s[0] # => "foo"
s[0] = "bar"
p s[0] # => "bar"

I usually make a little class with [] and []= methods that take no args 
in
the [], so I don't need the "0" and the [] suffix is equivalent to the *
prefix in C/C++.

Here would be an fairly efficient instance variable lvalue reference 
class:

class InstanceVariable
    def initialize(obj, var); @obj=obj; @var=var; end
    def []; @obj.instance_variable_get(@var); end
    def []=(val); @obj.instance_variable_set(@var, val); end
end
node = Object.new
node.instance_variable_set(:@next, nil)
node2 = Object.new
link = InstanceVariable.new(node, :@next)
p link[] # => nil
link[] = node2
p link[].equal?(node2) # => true
p node.instance_variable_get(:@next).equal?(node2) # => true

Here would be a more general class for referencing any lvalue:

class LValue
    def initialize(&lvalue); @lvalue = lvalue; end
    def []; eval(@lvalue[].to_s, @lvalue.binding); end
    def []=(val); eval("proc {|v| #{@lvalue[].to_s} = v}",
@lvalue.binding)[val]; end
end
def swap(a, b); b[], a[] = a[], b[]; end
x = 1
y = 2
swap(LValue.new { :x }, LValue.new { :y })
p x # => 2
p y # => 1

> > #zip doesn't help if you want to write, back-up, insert, delete, etc
> > during iteration.
> >
>
>  Correct.  For Array this could easily be build as an external class
> (attached is an experimental version).

For Array, there isn't a whole lot of value for an external iterator,
because we already have something that works as a poor man's replacement 
-
index (an integer).  The index can't do its own dereferencing (to read 
and
write an element), but Array can using an index.  In C++ STL, an 
external
iterator can't do all operations either.  To do an erase or insert for
example, you call a method on the container with an iterator.

I think external iterators are more useful for other data structures 
where
you don't have random access - linked lists, trees, etc.  I guess you 
could
provide an index-like API (but the index might not be an integer) 
instead of
a normal external iterator.

BTW, another external iterator we already have is IO, which operates at 
a
specific point in a file.

Eric

On Friday 06 June 2008 12:02:19 Jenda Krynicky wrote:
> David Masover wrote:
> > On Wednesday 04 June 2008 12:20:37 Star Cross wrote:
> > 
> >> Lesson: You can make Ruby every bit as messy as Perl if you want to.
> > 
> > Very true. But can you make Perl as pretty as Ruby?
> 
> BS. Not unexpected. Besides beauty is in the eye of the beerholder, 
> cleanliness likewise.

People who don't know me often make the mistake of assuming I ask 
rhetorical
questions.

I really don't think Perl can be made as pretty as Ruby, but then, Perl 
has
Acme::Lingua::Pirate::Perl, so anything's possible.

> > Every language can be made messy. Not every language can be made clean.
> 
> Agreed. For example with the meaningful newlines there are cases when 
> you can't make the Ruby code clean, because you either can't break the 
> overly long line or you can, but you end up with an operator lost on the 
> far right or with some silly line continuation character.

However, with required semicolons, you have every line looking ugly, 
except
just the edge cases. And that's just line endings -- never mind the
dereference operator and $calar prefix that become pretty much pure 
annoyance
for OOP.

Also, it's hardly unprecedented -- shells have had meaningful newlines 
with \
escaping forever.

> Robert Klemme (Guest) on 04.06.2008 23:00 wrote:
> > I have the impression that when writing Perl programs people usually 
> > use nested structures of arrays, hashes and scalars to represent
> > complex data whereas in Ruby land people - at least I - tend to rather
> > create classes and use them because it is so much easier than in Perl.
> 
> Or could it be that using the nested structures is harder in Ruby? 

Is it? Looks pretty easy to me.

> Oftentimes the classes are simple to make but do they give you anything? 

Yes, it's called Object-Oriented Programming. Perhaps not in every case, 
but I
would argue that because of how much more tedious Perl makes classes -- 
and
nice patterns like setters/getters -- there are going to be cases where 
a
separate class would really be appropriate, but Perl people will tend 
towards
data structures instead.

> Dave Bass (dogsbody) on 05.06.2008 17:01 wrote:
> > I find the contrary. Uncommented Perl is typically impossible to 
> > understand unless you wrote it yourself. It *is* possible to write 
> > clear Perl but, as with C, most people don't bother.
> 
> Uncommented hungarian is impossible to understand as well ... unless you 
> actually know that language. Or maybe you were talking about golf or 
> yaph or poetry?

I don't think this is a comment on the actual languages, but their 
respective
communities. If people are drawn to Ruby because of pretty syntax, 
they're
probably likely to hold clean, readable syntax as a desirable goal.

But that could also be a reflection of Perl having been around for so 
much
longer that it has a more diverse community.

I won't say more about that, though. I care more about being able to 
code
cleanly from scratch than how much clean code already exists to play 
with --
otherwise, I'd probably be using Perl, for CPAN alone.

On Friday 06 June 2008 12:21:08 Marc Heiler wrote:

> Then we compare our solutions. (Only "in-built" stuff is allowed, i.e. 
> no cpan modules rubygems etc... things would have to be used from 
> scratch, so that no language gains an inherent advantage over the other)

That would still potentially be a comparison of standard libraries. And 
you
can't get away from that, really.

But it is a valid point that beauty is in the eye of the beholder. 
Almost no
one I know who's seen Ruby code argues that Perl is better -- but then,
almost no one I know dislikes Firefly or Serenity. I'm finding out that 
the
Internet is a bigger place -- if there is an opinion, someone holds it.

Some people hate Firefly.

Phlip wrote:

>    $foo->{bar}(42);
> 
> Oh, and what does the 42 look like inside the method? local var = unshift?

Perl calling a method will look like

$foo->bar(42);

The argument 42 inside the method will normally look like

my $whatever = shift;

You don't usually want/need "local" these days. Note that if there are a
number of arguments you might do

my ($arg1, $arg2, ...) = @_;

AHS

On 6/7/08, Eric Mahurin <eric.mahurin@gmail.com> wrote:
> node2 = Object.new
>     def []; eval(@lvalue[].to_s, @lvalue.binding); end
> p y # => 1
Here is a little richer and more efficient solution:

class Ref
    def initialize(get=nil, &set); @get = get||set; @set = set; end
    def []; @get[]; end
    def []=(val); @set[val]; end
end
def Ref(get=nil, &set); Ref.new(get, set); end
def LValue(&lvalue)
    Ref.new(eval("proc { #{lvalue[].to_s} }", lvalue.binding),
            &eval("proc { |val| #{lvalue[].to_s} = val}"))
end
def InstVar(obj, var)
    Ref.new(lambda { obj.instance_variable_get(var) }) { |val|
        obj.instance_variable_set(var, val)
    }
end
def Attr(obj, attr, *args)
    get = obj.method(attr)
    set = obj.method("#{attr.to_s}=")
    if args.empty?
        Ref.new(get, &set)
    else
        # curry *args
        Ref.new(lambda { get[*args] }) { |val|
            set[*(args.clone<<val)]
        }
    end
end

# some examples

def swap(a, b); b[], a[] = a[], b[]; end

x = 1
y = 2
swap(LValue { :x }, LValue { :y }) # swap x an y
p x # => 2
p y # => 1

x = [1, 2, 3, 4]
y = [5, 6, 7, 8]
swap(Attr(x, :[], 0..2), Attr(y, :[], 3..3)) # swap x[0..2] and y[3..3]
p x # => [8, 4]
p y # => [5, 6, 7, 1, 2, 3]

x = Struct.new(:a).new(1)
y = Object.new; y.instance_variable_set(:@b, 2)
swap(Attr(x, :a), InstVar(y, :@b)) # swap x.a and y.@b
p x.a # => 2
p y.instance_variable_get(:@b) # => 1

On Jun 7, 10:41 am, David Masover <ni...@slaphack.com> wrote:
> one I know who's seen Ruby code argues that Perl is better -- but then,
> almost no one I know dislikes Firefly or Serenity. I'm finding out that the
> Internet is a bigger place -- if there is an opinion, someone holds it.

Not that I have anything to contribute, but now you have me thinking
about this entire discussion and Rule 34.

I'm scared.

On Fri, Jun 6, 2008 at 7:47 PM, Jenda Krynicky <jenda@cpan.org> wrote:
>> Todd
>
> Someone who doesn't know either language?

Yes

> Which would not help much
> 'cause that someone needs to know at least some other programming
> language to have any idea whatsoever what's going on in here and then
> which ever's closer to his/her language wins.

Agreed.

> Spanish makes more sense that English to a portuguese that doesn't know
> either, does it say anything about the relative complexity of the two
> languages?
>
> Beauty contests are a nice pretext for watching a few chicks in swimwear
> (or wet tshirts), but it's not a way to find the most beautiful girl of
> the USA in the year 2008. Cause there is no such thing.

Also, here I agree.

In any situation, you need a context for beauty, which you pointed
out.  I was subtly suggesting that if you remove the context, then
everyone would be on a level playing field.

What would you suggest?  A pissing contest?  Just curious.

Todd

David Masover wrote:
> I really don't think Perl can be made as pretty as Ruby, but then, Perl 
> has
> Acme::Lingua::Pirate::Perl, so anything's possible.

And I don't think Ruby can be made pretty at all.

>> > Every language can be made messy. Not every language can be made clean.
>> 
>> Agreed. For example with the meaningful newlines there are cases when 
>> you can't make the Ruby code clean, because you either can't break the 
>> overly long line or you can, but you end up with an operator lost on the 
>> far right or with some silly line continuation character.
> 
> However, with required semicolons, you have every line looking ugly, 
> except
> just the edge cases. And that's just line endings -- never mind the
> dereference operator and $calar prefix that become pretty much pure 
> annoyance
> for OOP.

I hate languages that do not use any sigil. I want to know what is a 
variable and what is not and be able to tell the difference at the very 
first glance. And not have to think about what methods, functions, 
classes, ... exist or might exist in the future when naming my 
variables.

And for the semicolons making every line look ugly ... every sentence in 
english ends with a dot, except for those that end with a question or 
exclamation mark. Does that make the sentences ugly? A statement in a 
program is a sentence and a sentence should end with a marker, not fall 
off at the end of line unless I bend backwards.

>> Oftentimes the classes are simple to make but do they give you anything? 
> 
> Yes, it's called Object-Oriented Programming. Perhaps not in every case, 
> but I
> would argue that because of how much more tedious Perl makes classes -- 
> and
> nice patterns like setters/getters -- there are going to be cases where 
> a
> separate class would really be appropriate, but Perl people will tend 
> towards
> data structures instead.

OOP is not a holly grail, the fact that something is made into a class 
with getters and setters doesn't make it any better in itself. A class 
that only has the default getters and setters is a pointless class. No 
matter how easy was it to create it. You should not be creating classes 
just because you can, you should do that because it allows for a cleaner 
code, because it allows you to hide some complexity from whoever's using 
that class.

> I don't think this is a comment on the actual languages, but their 
> respective
> communities. If people are drawn to Ruby because of pretty syntax, 
> they're
> probably likely to hold clean, readable syntax as a desirable goal.

I don't think people get drawn to Ruby because of pretty syntax. I think 
it's all marketing. Ruby on Rails is (or is it still?) hip. The new cool 
kid on the block.

Jenda

David Masover wrote:
> On Friday 06 June 2008 12:21:08 Marc Heiler wrote:
> 
>> Then we compare our solutions. (Only "in-built" stuff is allowed, i.e. 
>> no cpan modules rubygems etc... things would have to be used from 
>> scratch, so that no language gains an inherent advantage over the other)
> 
> That would still potentially be a comparison of standard libraries. And 
> you
> can't get away from that, really.
> 
> But it is a valid point that beauty is in the eye of the beholder. 
> Almost no
> one I know who's seen Ruby code argues that Perl is better

We all live in certain communities and we tend to socialize with people 
we have something in common with. So it's not such a surprise that a 
Ruby programmer knows a lot of people who like Ruby ;-)

Todd Benson wrote:
> On Fri, Jun 6, 2008 at 7:47 PM, Jenda Krynicky <jenda@cpan.org> wrote:
>> Beauty contests are a nice pretext for watching a few chicks in swimwear
>> (or wet tshirts), but it's not a way to find the most beautiful girl of
>> the USA in the year 2008. Cause there is no such thing.
> 
> Also, here I agree.
> 
> In any situation, you need a context for beauty, which you pointed
> out.  I was subtly suggesting that if you remove the context, then
> everyone would be on a level playing field.
> 
> What would you suggest?  A pissing contest?  Just curious.
> 
> Todd

I suggest to drop the idea. A beauty contest in this area is just a 
flamewar-sure-to-happen. And it's completely pointless, you can't 
convince anyone something (or someone) is more beautiful (or clean). And 
there's penty of both Perl and Ruby examples all around the Internet so 
there is no point to add yet another bunch.

Jenda

<...>
> And for the semicolons making every line look ugly ... every sentence in
> english ends with a dot, except for those that end with a question or
> exclamation mark. Does that make the sentences ugly?

In English you do not write every sentence on the separate line, hence
the need to have something to mark the end of the sentence.
Same in Ruby, if you put several statements in one line you use 
semicolons
to separate them.

> A statement in a program is a sentence and a sentence should end with
> a marker, not fall off at the end of line unless I bend backwards.

Yep, it ends. That marker is newline. Pretty good choice - it marks the 
end
of the statement and does not bring any visual clutter. I like this a 
lot,
others may not like it, but they have a bunch of other languages to 
choose from.
<...>

Regards,
Rimantas

2008/6/13 Jenda Krynicky <jenda@cpan.org>:

<snip>rant</snip>

You do not have to use Ruby if you do not like to.

>> I don't think this is a comment on the actual languages, but their
>> respective
>> communities. If people are drawn to Ruby because of pretty syntax,
>> they're
>> probably likely to hold clean, readable syntax as a desirable goal.
>
> I don't think people get drawn to Ruby because of pretty syntax. I think
> it's all marketing. Ruby on Rails is (or is it still?) hip. The new cool
> kid on the block.

That's not true for me.  I don't use Rails but I do use Ruby because
of its OO capabilities and the clean syntax.  I was attracted way
before the hype and I believe Rails did not even exist at that point
in time.

Regards

robert

On Fri, Jun 13, 2008 at 6:22 AM, Jenda Krynicky <jenda@cpan.org> wrote:
> Todd Benson wrote:
> I suggest to drop the idea. A beauty contest in this area is just a
> flamewar-sure-to-happen. And it's completely pointless, you can't
> convince anyone something (or someone) is more beautiful (or clean). And
> there's penty of both Perl and Ruby examples all around the Internet so
> there is no point to add yet another bunch.

I'm just going to have to agree with you again.  I'm torn, you see.  I
see elegance in Ruby, but at the same time get a little frustrated
with its flexibility; a taste of scariness even.  I'll continue to
favor the language over some popular other ones, because, for me, I
can read the code easier, even if the same thing is done several
different ways.

I should point out as a side note that I still haven't bought into the
whole "pragmatic" thing, simply because I don't think that programming
paradigm really trustfully exists yet, be it Perl, PHP, Ruby, Python,
whatever.  I guess I'm kind of old school in thinking "there's no free
lunch", and that's probably having to do with the database/engineer
background.  Ah, well, maybe I'll grow up.

Todd

From: "Rimantas Liubertas" <rimantas@gmail.com>
>From: "Jenda Krynicky" <jenda@cpan.org>
>> And for the semicolons making every line look ugly ... every sentence in
>> english ends with a dot, except for those that end with a question or
>> exclamation mark. Does that make the sentences ugly?
> 
> In English you do not write every sentence on the separate line, hence
> the need to have something to mark the end of the sentence.
> Same in Ruby, if you put several statements in one line you use semicolons
> to separate them.

Precisely.  Further, when we do write phrases on separate lines in 
English,
as in poetry, punctuation is placed where it belongs, not forced to 
appear
unnecessarily at the end of every line.


>From: "Jenda Krynicky" <jenda@cpan.org>
> I don't think people get drawn to Ruby because of pretty syntax. I think 
> it's all marketing. Ruby on Rails is (or is it still?) hip. The new cool 
> kid on the block.

To paraphrase David Heinemeier Hansson, "f*ck rails."

<grin>

Many on this list have been using ruby long before rails existed.

I was drawn from perl to ruby, eight years ago, because ruby (matz) had
achieved the seemingly impossible: an elegant synthesis of smalltalk and
perl.

I don't feel the need to use OO for everything, but I like OO as a tool.
And OO programming in perl _sucked_.  I used to think it was neat that
OO was grafted onto perl with the addition of a single keyword to the
language.  But it was such a pain to write OO code in perl, that I 
rarely
made the effort--even when I really wanted an object.  I can still 
recall
those disappointing deliberations: wow, this bit of functionality I'm 
about
to implement would be ideal as an object, . . . but . . . eyuuuch . . . 
too
much of a pain in the ass.  So, yes: syntax matters.


Regards,

Bill

Did you just join this mailing list to be a douchebag?

I can't believe this conversation is still going.  "OMG PERL AND RUBY
HAVE DIFFERNET SYNATXCES."  Yes.  They do.  If you hate Ruby's, that's
fine, but having worked with Perl, PHP, Java, and C# before I found
Ruby, I find it refreshing.  The cleaner syntax and more powerful
language structures make C# and friends feel brittle and old.

But everyone's entitled to their own opinion, of course.  Just don't
blame people digging Ruby on a web framework and "marketing" (whatever
that means).  That's just silly.

--Jeremy

On Fri, Jun 13, 2008 at 7:16 AM, Jenda Krynicky <jenda@cpan.org> wrote:
>>> you can't make the Ruby code clean, because you either can't break the
> I hate languages that do not use any sigil. I want to know what is a
>
>> data structures instead.
>> respective
> Posted via http://www.ruby-forum.com/.
>
>



--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

Hi --

On Sat, 14 Jun 2008, Jeremy McAnally wrote:

> Did you just join this mailing list to be a douchebag?

I think the word is "troll" :-)


David

David A. Black wrote:
> I think the word is "troll" :-)

Let's change the subject line, too.

Em Friday 13 June 2008, Joel VanderWerf escreveu:
> David A. Black wrote:
> > I think the word is "troll" :-)
>
> Let's change the subject line, too.

  Wouldn't be better leave thread die? JMO...

--
Davi Vidal
--
E-mail: davividal@siscompar.com.br
MSN   : davividal@msn.com
GTalk : davividal@gmail.com
Skype : davi vidal
YIM   : davi_vidal
ICQ   : 138815296

This discussion has almost died, so let's increase the ante...

I think the solution is much easier. Against perl.

Perl 5.x won't shake the world anymore. It can continue to exist for 100 
years but its impact will shrink and shrink. This is inevitable. Only a 
few perl hardcore fans refuse to accept this.
Maybe they should read http://www.reddit.com/r/programming/ daily. I do 
so and it is very rare to see ANYTHING of relevance come up in regard to 
perl.
(Maybe someone has a graph, but I think I read more lisp references 
there, than perl references)
I am not saying there aren't any new great apps in perl. I still see 
complicated solutions implemented in C and perl in bioinformatics for 
example. I am sure there are countless more areas, so perl will not 
become irrelevant SOON. It will be a long and slow death as gradually 
people will ditch it in favour for another language (probably only ruby 
and python to choose from, i dont think php alone can "replace" perl, 
but what one has to understand with php is that it lowered the entry 
barrier for new, younger coders. Being a "noob" is no problem, because 
they have DECADES of years in the life left to LEARN more.)

It is thus moot to discuss about features in perl or solutions in perl 
that are "better". Ruby's syntax beats perl's syntax easily (with eyes 
closed). Ruby's OOP approach beats perl anytime. I think in fact I could 
say that matz designed ruby to beat perl easily.

And perl is already lying on the ground right now ... no sense to jump 
on it further.

Perl 6 might be different as far as the "new" factor will be concerned, 
at least I know (or read) of people who are interested in it. I am sure 
the hordes of C hackers that like perl (there are many of them) will 
jump onto perl 6 bandwagon. Maybe perl 6 will generate a lot of interest 
and will manage to hold its promises. Up today one can not download perl 
6 AND use it easily (like perl 5.x) though, so this sounds like 
vaporware until it becomes a reality.

Knowing that perl 5 won't make a large difference anymore due to the 
pressure of php, python and ruby against it (on the "scripting language" 
environment), I believe perl borders on becoming irrelevant as time 
passes by.

The strongest faction of perl users, in my opinion, are the old C 
hackers who are too lazy to switch to python or ruby, and don't do any 
(or much) web development either. (I know a few that even write their 
blog stuff in C ... )
They will be quick to point out mistakes in any other language, but 
refuse to acknowledge bigger problems in perl largely. And who can blame 
them? If a tool works, it is totally fine to continue using it. Without 
php, ruby and python, I think perl might be still extremely popular. But 
pitted against these languages, perl showed it's 1980- age.

Comparing perl only to php might make perl a winner for most of everyday 
task http://tnx.nl/php but throwing python and ruby into the pool where 
people can choose from, will make it very very hard for anyone to pick 
up on perl first.
(And besides, if perl's www focus would have been very strong, maybe we 
would never have seen the rise of php.)

In fact why should anyone stop using Perl? And will people?
This is a question only perl can answer and I think the ruby mailing 
list is not the proper place to discuss what perl needs to do.

For me, ruby beats perl hands down. I am not even writing that much ruby 
code actually... It is much nicer to think in domain specific languages 
(or instructions, if one wants to say so), keeping the data in 
human-readable files, and have no real limit on where to use it 
specifically, be it www, GUI, console app or whatever. (People might 
come up with the speed issue, but speed is so overrated for everyday 
tasks ......)

The only complaint I can have about ruby is that the documentation could 
always be improved. The Pickaxe is great, but I think a language should 
have at least a great online and up-to-date reference, similar to php, 
on the official site.

Em Friday 13 June 2008, Marc Heiler escreveu:
[...]
> The only complaint I can have about ruby is that the documentation could
> always be improved. The Pickaxe is great, but I think a language should
> have at least a great online and up-to-date reference, similar to php,
> on the official site.

  Indeed. I really need this!

  rdoc & ri & irb are great, but php.net/function-name is almost perfect 
with
examples and comments and description and parameters and return values.

  Best regards,
--
Davi Vidal
--
E-mail: davividal@siscompar.com.br
MSN   : davividal@msn.com
GTalk : davividal@gmail.com
Skype : davi vidal
YIM   : davi_vidal
ICQ   : 138815296

On Fri, Jun 13, 2008 at 12:23 PM, Joel VanderWerf
<vjoel@path.berkeley.edu> wrote:
> David A. Black wrote:
>>
>> I think the word is "troll" :-)
>
> Let's change the subject line, too.

Is that what they mean by cross-fertiliser?

martin

Robert Klemme wrote:
>>> they're
> in time.
>   
Ditto . I'm programming in Ruby for more than 6 years now and I still
haven't used Rails :).
Clean syntax, beautiful code, enjoyment in programming!
V.-

On Sat, 2008-06-14 at 04:43 +0900, Davi Vidal wrote:

> > The only complaint I can have about ruby is that the documentation could
> > always be improved. The Pickaxe is great, but I think a language should
> > have at least a great online and up-to-date reference, similar to php,
> > on the official site.



>   Indeed. I really need this!



>   rdoc & ri & irb are great, but php.net/function-name is almost perfect with 
> examples and comments and description and parameters and return values.


What's the actual procedure for improving Ruby's docs?  Is there a doc
team?  If there is, is it active?  If it is, does it accept suggestions,
patches and/or wholesale chapters?  If so, and here's the key part, is
it actually possible to contribute without a huge bureaucratic
nightmare?

A lot of communities fail on that last point.  Is Ruby's one of them?
(I am asking because I don't know, not because I think this is the
case.)

On Friday 13 June 2008 06:16:00 Jenda Krynicky wrote:

> I want to know what is a 
> variable and what is not and be able to tell the difference at the very 
> first glance.

Difference of philosophy -- with the simple setters and getters, the 
idea is
to start using it as a variable, but it might not always be.

> And not have to think about what methods, functions,  
> classes, ... exist or might exist in the future when naming my 
> variables.

So you still have to think about what methods (or functions) exist when 
naming
your methods (or functions). No one's stopping you from naming variables 
like
var_foo -- or using mostly instance variables, like @foo (which does 
have a
sigil).

> And for the semicolons making every line look ugly ... every sentence in 
> english ends with a dot, except for those that end with a question or 
> exclamation mark. Does that make the sentences ugly?

I don't think so, but I do think it would make syntax ugly, if syntax 
were
written the way prose were:

while line = gets; fields = line.split("\t"); puts fields[3]; end

As someone else pointed out, in mediums where sentences aren't always 
written
as part of paragraphs, the period is often dropped -- poetry, for 
example, or
instant messaging.

> OOP is not a holly grail,

Strawman -- I didn't say that.

> the fact that something is made into a class  
> with getters and setters doesn't make it any better in itself. A class 
> that only has the default getters and setters is a pointless class. No 
> matter how easy was it to create it.

Actually, there is a point -- such a class is abstract. Contrived 
example:

class Person
  attr_accessor :name, :income, :disposition
end

class Employee < Person
  def income
    if disposition == :rebellious
      0
    else
      @income
    end
  end
end

Simple translation: A class can have its attributes overridden -- or you 
can
outright pass in an object that isn't even inherited, but provides the 
needed
methods.

A hash, say, makes this much clumsier, though it can still be done.

> I don't think people get drawn to Ruby because of pretty syntax. I think 
> it's all marketing. Ruby on Rails is (or is it still?) hip. The new cool 
> kid on the block.

You know, I saw an interview question to DHH, asking him why he chose 
Ruby. It
was all about which language would allow him to write "the most 
beautiful
code." Or, in other words, it was all about pretty syntax.

On Fri, Jun 13, 2008 at 9:17 PM, David A. Black <dblack@rubypal.com> 
wrote:
> Hi --
>
> On Sat, 14 Jun 2008, Jeremy McAnally wrote:
>
>> Did you just join this mailing list to be a douchebag?
>
> I think the word is "troll" :-)

Right, Jenda is one of the most intelligent trolls I have ever seen,
he takes care to write some reasonable posts once in a while and then
he just continues to waste bandwith and all the nice things trolls do,
unless his brain has an on-off switch of course.
Please be aware that I do by no means indicate that he has a brain,
this is beyond my abilities to prove, but as I have called him
intelligent he probably has one, unless he found a ghost writer for
the non trollish posts.

I really feel it is good to have him around, makes this list more like
real life, full of people one would consider calling bad names. I do
not do that however because we have a nice saying here in France:
"Stupid is a property of people who do not think like you" (well
language is actually  worse "Un con c'est quelqu'un qui pense
differement que toi").

Dear Kenda maybe you can however find other things to do for some
while, I guess you harmed yourself enough for now.
And just in case you did not notice, this is a non sigil language
mailing list, so you probably posted by error. Do not apologize
however as you are forgiven already :).

Cheers and keep not seeing you out there.
Robert
>
--
http://ruby-smalltalk.blogspot.com/

---
As simple as possible, but not simpler.
Albert Einstein

From: "Bill Kelly" <billk@cts.com>
>>From: "Jenda Krynicky" <jenda@cpan.org>
>> I don't think people get drawn to Ruby because of pretty syntax. I think 
>> it's all marketing. Ruby on Rails is (or is it still?) hip. The new cool 
>> kid on the block.
> 
> To paraphrase David Heinemeier Hansson, "f*ck rails."
> 
> <grin>

Apologies for replying to my own post - but it's been bothering me that 
I forgot
to add a footnote to explain my comment above.  And so I worried it 
might have
sounded harsh to those not familiar with the event my comment puns on.

Thus, here's the footnote I might ought to have included:
http://blog.wekeroad.com/blog/imploding-rails-jesu...
http://www.codinghorror.com/blog/archives/001065.html
(scroll down about a page)


All in fun,

Bill

> You can get bitten by this. Everything is call-by-reference, not 
> call-by-value as in Perl, C etc. Change a function's parameter and you 
> change the original, not a local copy of it.

Perl is call-by-reference when you modify the arguments array @_ 
directly.
It is call-by-value when you copy the arguments (which is the 
convention).
<verbatim>
sub cbr{ $_[0]++ }
$var = 1;
cbr($var);
print $var; # gives 2

sub cbv{ my ($foo) = @_; $foo++ }
$var = 1;
cbv($var);
print $var; # gives 1
</verbatim>

>> Also, it helps you appreciate one of the ways that Perl is more readable
>> than its counterpart.
> 
> I find the contrary. Uncommented Perl is typically impossible to 
> understand unless you wrote it yourself. It *is* possible to write clear 
> Perl but, as with C, most people don't bother.

People just love to be lazy.
However I find that given the right tools (use strict; perltidy, 
perlcritic, a good ide e.g. Eclipse/Epic) it is relativly easy to write 
maintainable perl code.

> However I find that given the right tools (use strict; perltidy, 
> perlcritic, a good ide e.g. Eclipse/Epic) it is relativly easy to write 
> maintainable perl code.

Compared to what? It takes discipline to write good code. Some languages 
make it easier.

Maintanable is something completely different though. I find it hard to 
maintain code someone else wrote. I need time to dig into it, and often 
I just adjust his style to my style (no matter what language was used).

Well written code is always better than badly written code.

I also think to compare pure source code one should only use notepad, 
and in this scenario ruby beats perl with eyes closed any time ;)