[ruby-talk:01538] Re: Programming Languages

Hi,

I contacted Mr. Waclena 
(from http://www.lib.uchicago.edu/keith/crisis/langs/languages.html), 
and fortunately, he gave a quick perspective on Ruby.
(He has been using Python since his crisis).

I am including an abridged version of his response below.
I think this is valuable input that will help give some
orientation to documentation needs and otherwise address
some concerns from an objective perspective.

Keith Waclena wrote:
> 
> Hi!
> 
> >>>>> "GNH" == gnhurst  <[e-mail]> writes:
> 
> GNH> I read your pages with interest.  I noticed they are somewhat
> GNH> dated, so I'm hoping you are still around to get this.
> 
> Yes, I haven't touched them since Python put an end to my crisis.  I
> also haven't had much time to continue evaluating languages, except
> for small tool-languages like gema.  I do have a long-standing
> interest in investigating ocaml, since it came off so well in my
> investigation -- but no time.
> 
...
> GNH> Then I just last week came across 'Ruby'.  I wonder how you would
> GNH> analyze this one.  Here's the link: http://www.ruby-lang.org
> 
> Hmm, I haven't heard about this one.  After reading my web pages,
> people often point me at other languages, which I usually reject
...
> I must say after looking at the Ruby web site that it looks *really*
> interesting.  I will definitely grab it and (if I can somehow find the
> time) play with it.
> 
> Here are my initial thoughts after just reading *some* of the web page
> (ie, I'm really talking off the top of my head here...):  my comments
> are prefixed with *.
> 
> Perl
> 
> Ruby owes a lot of ideas Perl.
> 
> * This is al little scary, but I'll be brave.
> 
> Now, let's compare Perl with Ruby:
> 
>       Ruby was a genuine easy-to-use object-oriented language from the
>       beginning; whereas Perl's OOP features were added to non-OO
>       Perl, so that these features are (unlike the rest of Perl) very
>       clumsy and hard to use correctly and effectively.
> 
> * I agree with this statement (except for the qualifying `unlike'...
> 
>       Ruby uses less punctuation ($,@,%, etc.) Ruby uses ($,@)
>       prefixes to denote variable scope, not data type.
> 
> * This sounds like a huge improvement, though I'm not crazy about such
>   prefixes in general.  Could be okay if they're not required much.
> 
>       The default variable scope rules for Ruby (default: local) are
>       much better suited for medium-to-large scale programming tasks;
>       no "my, my, my" proliferation is needed for safe Ruby
>       programming.
> 
> * A huge win.
> 
>       Ruby copies many good capabilities of Perl, ranging from $_
>       short cuts to extended regular expressions.
> 
> * Hmm, I really hate Perl's implicit shortcuts, so this makes me
>   nervous.
> 
>       Perl is statically typed language except for references. The
>       only types in Perl are scalar, array, hash and type glob. :-)
> 
> * Indeed.  I hope this means that Ruby has real aggregate datatypes
>   like Python does.
> 
> Python
> 
> Python and Ruby deal with similar problem areas. Now, let's compare
> Python with Ruby:
> 
>       Ruby uses conservative statement structure, using `end'.
> 
> * Unimportant to me in and of itself, although I'm guessing that this
>   is connected to the fact that Ruby is more of an expression language
>   than Python (ie everything has a value), which I would like.
> 
>       You don't have to say `self.' to access attribute of the object.
> 
> * Replacing self with some punctuation seems pointless to me -- I
>   might actually prefer the use of self.  I am kind of amazed that the
>   ability to say @foo is perceived by the Ruby people as such a big
>   improvement over self.foo, but okay.
> 
>       All data (including Integer, String, List, etc.) in Ruby are class instances.
> 
> * This is excellent; the inability to subclass fundamental Python
>   datatypes (like dictionaries and files) is very annoying.
> 
>       Ruby has a better (or real) closure feature.
> 
> * Also excellent; Python's half-***** closures are very annoying.
> 
>       Object attributes are not accessible by default in Ruby.
> 
> * A minor win, perhaps.
> 
>       Ruby's functions (methods) are not first class objects.
> 
> * Well, this sounds so bad that I can't really believe it means what
>   it sounds like.
> 
>       Ruby converts small integers and long integers automatically.
> 
> * So does Python actually.
> 
>       Ruby does not have tuples.
> 
> * Hard to evaluate this.  Python has tuples as well as lists because
>   tuples are immutable: this allows them to be used as, for instance,
>   keys in dictionaries without any confusion, and this has always
>   seemed to me a good idea.  If Ruby doesn't have tuples, that's okay
>   as long as it deals with the deep issues properly.
> 
>       Statements in Ruby have values; you can say
> 
>             def max(a,b)
>               if a>b then a else b end
>             end
> 
> * This is what I mean by an expression language.  Guido (Python's
>   author) hates this, but I prefer it.
> 
>       Ruby has assignment syntax sugar such as +=, -=, etc.
> 
> * While I hate C's ++ and -- operators (I think they cost far more in bugs
>   than they save in typing) I miss assignment operators like +=
>   (because I think they decrease bugs by eliminating the need to keep
>   left hand sides and right hand sides in sync as code is modified).
> 
>       Ruby has more natural operator overloading; e.g. you can define
> 
>             def +(x)
>              self.to_i + x
>             end
> 
> * I'm of two minds about operator overloading, but I don't hold it
>   against a language.
> 
>       Ruby has real garbage collector, not ref-counting. So that:
>             Not subject to memory leaks like ref-counting is.
>             No INCREF, DECREF are required for extensions.
> 
> * Fantastic.
> 
>       Ruby has a loop abstraction using block; e.g.
> 
>             10.times do
>               ...
>             end
> 
>       You can define your own arbitrary iterator.
> 
> * Seems reasonable -- don't think I can really appreciate what this
>   means yet.
> 
>       Ruby's block for method can be used more than iterator; e.g.
> 
>             mutex.synchronize do
>               .. critical process ..
>             end
> 
> * Ditto.
> 
>       Ruby provides method combination using `super'.
> 
> * Good.
> 
>       Ruby is often faster than Python.
> 
> * Can't complain about that.
> 
> Tcl
> 
> Tcl is well-known as a scripting and glue language, but much simpler
> than Perl. Now, let's compare Tcl with Ruby:
> 
>       Ruby has various GUI toolkits, of cource including Tk.
> 
> * Good.
> 
> Java
> 
> Java is the language in the news one way or another. Now, let's
> compare Java with Ruby:
> 
>       Ruby is an intepreted language.
> 
> * I think this issue is one of the most muddled in programming
>   language comparisons.  Excluding really exotic languages, no
>   language is inherently interpreted rather than compiled.  That
>   distinction is a characteristic of an implementation, not of a
>   language.  Of course, some language features can make traditional
>   compilation techniques difficult -- Python has problems here because
>   it's so dynamic -- but clever people have figured out how to compile
>   good code for some very dynamic languages.  For a minor example,
>   look at the difference between tcl v7 and v8.  For a more
>   significant example, look at self.  Common Lisp is another good
>   example.
> 
>   Anyway, I don't see `Ruby is an intepreted language' as being a
>   useful statement.  A statement like `Ruby has a handy interactive
>   interpreted implementation' -- like Python, or, better, Lisp Forth
>   or Smalltalk -- is a useful statement.  A statement like `Ruby
>   doesn't have a high-performance compiled implementation -- like C or
>   Self or Lisp -- is also a useful statement (albeit a sad one).
> 
>   My continued interest in ocaml stems in part from the availability
>   of a fast interpreter plus an extremely high-performance native-code
>   compiler.  Ideally all languages would have such a dual
>   implementation, or else a true incremental compiler like self's.
> 
>       Ruby's module can be used to share implemantation among classes.
> 
> * This sounds interesting.
> 
>       Ruby's variable and expressions are not statically typed.
> 
> * This is too bad, but no worse than Python.
> 
> Thanks for the pointer!
> 
> /k
> ...

Guy N. Hurst