Re: [FWP] Anybody look at Ruby? [LONG POST]

[John Porter <jdporter@min.net>]

John Carter wrote:
> Thanks for your post, I've being longing for a FWP type to give me an
> opinion on Ruby. 

Maybe this thread is more appropriate elsewhere (like clpm?), but...

After skimming the Ruby docs, I can say with some confidence that
Ruby has enough "features" to make a Perler as uneasy with it as
with Python.  In fact it resembles Python in certain respects.
After all, Ruby's creator seems to have been influenced mainly
by these two langauges.

On that topic, note what the creator (matz) has to say:

"1993... I knew Perl (Perl4, not Perl5), but I didn't like it really,
because it had smell of toy language (it still has).
I knew Python then. But I didn't like it, because I didn't think it
was a true object-oriented language. OO features are appeared to be
add-on to the language."

Well, if this his expert estimation of Perl and Python, one has to
wonder how well-designed his language could possibly be!

Anyway, as for technicalities.

Ruby does not use semicolons to terminate lines; it used newlines.
It's kinda like Basic, I guess, in that respect.  It has both
begin/end and { } to denote blocks, although I'm not sure if 
they're synonymous, or what.  You define a named routine thus:
  def foo
    ...
  end
and an anonymous routine thus:
  foo = proc { ... }
Ruby is LESS consistent than Perl?!?!?


All values are stored and passed by reference.  Thus, if you say
    a = "foo"
    b = a
    a.concat("bar")
you will find (probably to your consternation) that b ALSO contains
"foobar".  There must be a way around this, maybe involving other
methods of the string class...
Ruby is a "pure" OO language.
"Assignment just copies object references, and parameter passing is
equivalent to assignment. This means you can end up with multiple
variables referencing the same object. If one of those variables is
used to invoke a destructive method, the object referenced by all
of them will be changed."

Of course, with all that automagical reffing/dereffing going on,
you have to explicitly deref in some situations; for that, ruby
provides the * (star) operator.


Here's something I would have to consider very poorly designed.
Ruby doesn't have the type-signifying characters on identifiers
the way Perl does[1], yet, like perl, it allows func calls with
no params to omit the parens.  Thus
	foo = bar
could be either a call to function bar, or an access to variable
bar.  To decide, ruby does a very strange thing:  it examines
the preceding lexical context for assignments.  If it finds
anything like
	bar = "value"
it decides that bar is a variable; otherwise it tries to call
it as a function.  Note that it does NOT examine the entire
lexical context; thus you can have (what the faq calls a 
"pathological" case; I disagree):

	foo = bar
	bar = "value"
	foo = bar

and in the first line, bar variable is accessed and in the third
line the bar func is called.  I'm not sure, but this leads me to
suspect that ruby is doing line-at-a-time interpretation, thus
breaking something very nicely fixed in perl.  
The faq's suggestion to work around this "rare" problem is to
"try putting a foo = nil line" in before the first access to foo.

[1] That is, it has them, but uses them in a different way. 
Whereas Perl lets the suitably irregular fileglob go unsymbolized,
Ruby lets normal variables and function names suffer from that
deficiency.  Not a wise choice, IMHO.
Anyway, global variables start with $, and Ruby shamelessly
copies Perl's: $!, $1, $/, $\, $@, etc.
Class instance variables (i.e. named data members) have the
"@" symbol prepended.


Ruby follows Perl's lead in many things.  For example:
	Perl	Ruby
	q()	%q()
	qq()	%Q() or %()
	qw()	%w()
	qx()	%x()
	qr()	%r()
As mentioned above, all values are handled by ref, so the
standard way to create arrays and hashes is via [ .... ]
and { foo => bar, ... }.


Of course, Ruby has "wisely" eliminated what is perhaps Perl's
greatest strength, namely, context.  Returning lists of values
is supported, but it lacks Perl's intrinsic support for
list-oriented functional programming.  This, IMHO, is Ruby's
(and Python's) fatal flaw.


-- 
John Porter

Since time is short, and you may lie, I'm going to have to torture you.


==== Want to unsubscribe from Fun With Perl?  Well, if you insist...
==== Send email to <fwp-request@technofile.org> with message _body_
====   unsubscribe