Forum: Ruby A crosspost from the Perl Community

74e3bf2025c7a66842cc35dd959bd4b1?d=identicon&s=25 Star Cross (starx)
on 2008-06-04 19:21
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
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2008-06-04 21:49
(Received via mailing list)
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.
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2008-06-04 22:01
> 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
Ac0085dae0703db56ad7f8cb9e1798ba?d=identicon&s=25 Phillip Gawlowski (Guest)
on 2008-06-04 22:24
(Received via mailing list)
-----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-----
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-06-04 23:00
(Received via mailing list)
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
97550977337c9f0a0e1a9553e55bfaa0?d=identicon&s=25 Jano Svitok (Guest)
on 2008-06-04 23:46
(Received via mailing list)
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.
D7908f05c89e965f6bc5308ad6f41256?d=identicon&s=25 Siep Korteling (steenslag)
on 2008-06-05 00:17
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
Afe54b334a1e61ab6644ee80b236e94e?d=identicon&s=25 Arved Sandstrom (Guest)
on 2008-06-05 14:40
(Received via mailing list)
"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
9d751d4cd704a4efe3a335c77c4487a3?d=identicon&s=25 Dave Bass (dogsbody)
on 2008-06-05 17:01
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!  ;-)
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2008-06-05 17:37
(Received via mailing list)
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})
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2008-06-05 22:10
(Received via mailing list)
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
9d751d4cd704a4efe3a335c77c4487a3?d=identicon&s=25 Dave Bass (dogsbody)
on 2008-06-06 13:33
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
F4fcd10896e4ec41dd5bf48ee114e959?d=identicon&s=25 Arved Sandstrom (Guest)
on 2008-06-06 14:16
(Received via mailing list)
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
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2008-06-06 14:19
(Received via mailing list)
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.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-06-06 14:31
(Received via mailing list)
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
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2008-06-06 17:03
(Received via mailing list)
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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-06-06 17:52
(Received via mailing list)
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
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2008-06-06 18:18
(Received via mailing list)
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.)
88521907e2c9c585bc94e35a38893dc5?d=identicon&s=25 Jenda Krynicky (jendaperl)
on 2008-06-06 19:03
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
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2008-06-06 19:22
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)
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2008-06-06 19:25
> 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
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2008-06-06 19:31
> 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.
88521907e2c9c585bc94e35a38893dc5?d=identicon&s=25 Jenda Krynicky (jendaperl)
on 2008-06-06 20:28
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
289cf19aa581c445915c072bf45c5e25?d=identicon&s=25 Todd Benson (Guest)
on 2008-06-07 02:33
(Received via mailing list)
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
88521907e2c9c585bc94e35a38893dc5?d=identicon&s=25 Jenda Krynicky (jendaperl)
on 2008-06-07 02:48
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
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2008-06-07 04:32
(Received via mailing list)
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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-06-07 14:30
(Received via mailing list)
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
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2008-06-07 16:39
(Received via mailing list)
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
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2008-06-07 17:38
(Received via mailing list)
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.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2008-06-07 17:43
(Received via mailing list)
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.
F4fcd10896e4ec41dd5bf48ee114e959?d=identicon&s=25 Arved Sandstrom (Guest)
on 2008-06-07 19:13
(Received via mailing list)
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
C35ede9febe86d05f8b45c67191de495?d=identicon&s=25 Eric Mahurin (Guest)
on 2008-06-07 22:13
(Received via mailing list)
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
Bc8e3e2f7acb3a7d93c10e235dc0b4e1?d=identicon&s=25 yermej (Guest)
on 2008-06-08 00:08
(Received via mailing list)
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.
289cf19aa581c445915c072bf45c5e25?d=identicon&s=25 Todd Benson (Guest)
on 2008-06-09 13:14
(Received via mailing list)
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
88521907e2c9c585bc94e35a38893dc5?d=identicon&s=25 Jenda Krynicky (jendaperl)
on 2008-06-13 13:16
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
88521907e2c9c585bc94e35a38893dc5?d=identicon&s=25 Jenda Krynicky (jendaperl)
on 2008-06-13 13:19
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 ;-)
88521907e2c9c585bc94e35a38893dc5?d=identicon&s=25 Jenda Krynicky (jendaperl)
on 2008-06-13 13:23
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
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2008-06-13 13:52
(Received via mailing list)
<...>
> 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
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2008-06-13 15:05
(Received via mailing list)
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
289cf19aa581c445915c072bf45c5e25?d=identicon&s=25 Todd Benson (Guest)
on 2008-06-13 17:32
(Received via mailing list)
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
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2008-06-13 18:41
(Received via mailing list)
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
6d3c187a8b3ef53b08e3e7e8572c4fea?d=identicon&s=25 Jeremy McAnally (Guest)
on 2008-06-13 19:01
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2008-06-13 21:18
(Received via mailing list)
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
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2008-06-13 21:28
(Received via mailing list)
David A. Black wrote:
> I think the word is "troll" :-)

Let's change the subject line, too.
4cd3615da7c39beacaaab174267ad8b2?d=identicon&s=25 Davi Vidal (Guest)
on 2008-06-13 21:31
(Received via mailing list)
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
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2008-06-13 21:34
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.
4cd3615da7c39beacaaab174267ad8b2?d=identicon&s=25 Davi Vidal (Guest)
on 2008-06-13 21:45
(Received via mailing list)
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
Ae16cb4f6d78e485b04ce1e821592ae5?d=identicon&s=25 Martin DeMello (Guest)
on 2008-06-13 23:12
(Received via mailing list)
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
Cfdeff3ac35010e4de8f85d954f24f4a?d=identicon&s=25 Vassilis Rizopoulos (Guest)
on 2008-06-14 01:27
(Received via mailing list)
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.-
0ab5dce3e32b6cafa5ba92c2c0509947?d=identicon&s=25 Michael T. Richter (Guest)
on 2008-06-14 02:43
(Received via mailing list)
Attachment: signature.asc (190 Bytes)
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.)
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2008-06-14 20:57
(Received via mailing list)
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.
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2008-06-14 21:38
(Received via mailing list)
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
4feed660d3728526797edeb4f0467384?d=identicon&s=25 Bill Kelly (Guest)
on 2008-06-14 23:05
(Received via mailing list)
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
7b7370616ecc84d8cc6f056d8c0cfd73?d=identicon&s=25 Joerg Meltzer (codeacrobat)
on 2008-06-22 19:19
> 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.
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2008-06-22 19:32
> 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 ;)
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.