Re: Ruby and OO

[Eli Collins <address@hidden>]

As a Ruby user I don't think there are *huge* practical implications
of its deep OO, that being said I find ruby code is much more readable
than perl, while remaining terse. In some cases the syntax
just looks better; e.g.

1.upto(100) { |i| puts i }

Which I value since I have to read a lot of programs (i think perl's
class syntax is horrid). I also find writing ruby suits my internal
logic because it does not rely on syntactic sugar (a literal number is
an object and has an upto method), or global functions (php).

Once you understand that everything is an object, IO doesn't require
lots of syntax to memorize (like perl). e.g. the perl

while <> {
   print if /Ruby/
}

is equivalent to the ruby:

print ARGF.grep /Ruby/

I recently wrote a small ESS (evolutionary stable strategy)  rat
simulation in ruby. One piece of logic is that rats in the global pool
of rats will "meet" each other a certain number of times (as long as
at least two rats are still alive). The ruby for this was:

@numMeetings.times { twoRatsMeet if moreThanOneRatLeft }

I have rewritten small java apps in ruby and they have been half the
size, but more importantly much easier to read (no primitive/object or
typecasting uggliness). There are many many other things about ruby
which I have found that make it more attractive, you don't really
appreciate these until you start to push the language, at least
enough to need blocks, propper iterators, etc. If you're just doing
basic file processing then perl is of course more than enough.

give this quick introduction a try:

http://www.pragmaticprogrammer.com/talks/introruby/introruby.htm

Eli




On Tue, 27 Nov 2001, Paul Prescod wrote:

> I'd like to hear more about the practical implications of Ruby's deep
> OO. I mean if Ruby internally treats loops and conditionals and scripts
> as objects and methods that seems to me to be only a problem if it
> causes some confusion or difficulty for the programmer. Reducing the
> number of conceptual objects in the inner core of a language is good
> unless it makes programming difficult in which case it is bad. If you
> write a grotty Perl-style regular expression and then find out that
> under the covers it is really OO I see that as a benefit, not a price.
> It means that you CAN treat it as an object and do OO things on it if
> you want. Or you can (hopefully) ignore the OO-ness of it.
>
> Does anyone complain about CLOS that underneath it all it is really just
> "macros and functions"?
>
> Also, I'm not convinced Python is that far off (for better or worse).
> You could think of functions in a Python script as methods on the module
> object. It's a little painful to get the reference to that object but it
> can be done (sys.modules["__main__"]).
>
> I am not a Ruby user myself so I am looking for enlightement on that
> issue. I feel that people would not have complained about it if there
> were not a deeper issue than just that the manual said that even stuff
> that looks non-OO really is.
>
>  Paul Prescod
>