Forum: Ruby Ruby vs Perl performance

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
2d8b8b3782611eae032f194a900db4ef?d=identicon&s=25 Vetrivel Vaithilingam (vetrivel)
on 2009-02-07 14:35
Attachment: performanceTime.pl (5 KB)
I have downloaded perl and ruby program in net.I run both the
programs.But the Ruby program performance very wost than perl.Can any
one tell me the reasons and
soultion to make ruby as faster than perl.
I have attached perl program.


#!/usr/local/bin/ruby

BAILOUT = 16
MAX_ITERATIONS = 1000

class Mandelbrot

        def initialize
                puts "Rendering"
                for y in -39...39 do
                        puts
                        for x in -39...39 do
                                i = iterate(x/40.0,y/40.0)
                                if (i == 0)
                                        print "*"
                                else
                                        print " "
                                end
                        end
                end
        end

        def iterate(x,y)
                cr = y-0.5
                ci = x
                zi = 0.0  while(1)
                        i += 1
                        temp = zr * zi
                        zr2 = zr * zr
                        zi2 = zi * zi
                        zr = zr2 - zi2 + cr
                        zi = temp + temp + ci
                        return i if (zi2 + zr2 > BAILOUT)
                        return 0 if (i > MAX_ITERATIONS)
                end

        end

end

time = Time.now
Mandelbrot.new
puts
puts "Ruby Elapsed %f" % (Time.now - time)

                zr = 0.0
                i = 0
0bfcd61fc289de2e441929ecfd00b0ed?d=identicon&s=25 Peter Hickman (Guest)
on 2009-02-07 15:45
(Received via mailing list)
Can't be done. Unless you intend to build your own super fast vm.

On my box Perl consistently runs in around 2 seconds, Ruby takes 9.

There is nothing that can be done to the source (other than getting
the code to actually compile - your source is broken) that can improve
more than a second or so on that performance.

Haven't tried it under JRuby though, you might experience better
performance there.

But to honest I wouldn't sweat it that Ruby is not the best tool for
this sort of thing (number crunching), my wife's car cannot best a
dragster but it gets her where she needs to be.
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-02-07 16:58
Vetrivel Vetrivel wrote:
> I have downloaded perl and ruby program in net.I run both the
> programs.But the Ruby program performance very wost than perl.Can any
> one tell me the reasons and
> soultion to make ruby as faster than perl.

Try ruby 1.9?
-=r
Aaca034456897ccbc8bb14953c4a41c1?d=identicon&s=25 Radosław Bułat (radarek)
on 2009-02-07 17:57
(Received via mailing list)
On Sat, Feb 7, 2009 at 2:35 PM, Vetrivel Vetrivel
<vetrivel.bksys@gmail.com> wrote:
> I have downloaded perl and ruby program in net.I run both the
> programs.But the Ruby program performance very wost than perl.Can any
> one tell me the reasons and
> soultion to make ruby as faster than perl.
> I have attached perl program.
>

Did you take code form this site:
http://www.timestretch.com/FractalBenchmark.html ?

Try it with ruby1.9.1. I get about 1.90s for perl and 2.80s for
ruby1.9.1 so it's not bad.
--
Pozdrawiam

Rados³aw Bu³at
http://radarek.jogger.pl - mój blog
Aaca034456897ccbc8bb14953c4a41c1?d=identicon&s=25 Radosław Bułat (radarek)
on 2009-02-07 18:06
(Received via mailing list)
On Sat, Feb 7, 2009 at 3:42 PM, Peter Hickman <peterhi@ntlworld.com>
wrote:
> Haven't tried it under JRuby though, you might experience better performance
> there.
>

JRuby is faster than 1.9 even without warming. ~2s for jruby, ~2.8s
for ruby1.9.1. With warm up it goes down to ~1.2s and with --fast flag
to ~0.75s.


--
Pozdrawiam

Rados³aw Bu³at
http://radarek.jogger.pl - mój blog
F065301eb65a5d0da8edcb8de9d5e28e?d=identicon&s=25 Tim Greer (Guest)
on 2009-02-07 19:20
(Received via mailing list)
Vetrivel Vetrivel wrote:

> I have downloaded perl and ruby program in net.I run both the
> programs.But the Ruby program performance very wost than perl.Can any
> one tell me the reasons and
> soultion to make ruby as faster than perl.
> I have attached perl program.
>

You're not going to make it run faster (not at this time anyway).  You
can always likely improve and code more efficiently, but some things
are just going to be faster.
46a8ebdfabc2485407f89a2db5bdafb7?d=identicon&s=25 Igor Pirnovar (rooby)
on 2009-02-07 19:23
Vetrivel Vetrivel wrote:
> I have downloaded perl and ruby program in net.I run both the
> programs.But the Ruby program performance very wost than perl.
> Can any one tell me the reasons and soultion to make ruby as
>faster than perl. I have attached perl program.


Ruby and Perl are two totally different programing environments and are
really not to be compared with regards to their run time performance.
With Ruby the performance issue is shifted to the entire project life
cycle, and indeed to the complexity of the project. Mere execution time
of an application represents only a tiny fraction of what is truly
measured when comparing procedural language like Perl and object
oriented Ruby. If you compare the two languages in this respect Perl
doesn't come even close to where Ruby stands. In fact I believe if you
look at performance issues from this angle, Ruby stands out very proudly
as the best performing programming language of all times.
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-07 22:15
(Received via mailing list)
Vetrivel Vetrivel wrote:

> MAX_ITERATIONS = 1000
>
> class Mandelbrot
>
>         def initialize
>                 puts "Rendering"
>                 for y in -39...39 do
>                         puts
>                         for x in -39...39 do
>                                 i = iterate(x/40.0,y/40.0)

Don't indent so deeply.  It makes the code much harder to read.

Don't write a mandelbrot program in an interpreted language.
Write it in a compiled language like OCaml.
Cd6b438f1238ee36cf4daecbae1d3917?d=identicon&s=25 Thomas Preymesser (Guest)
on 2009-02-07 23:35
(Received via mailing list)
2009/2/7 Vetrivel Vetrivel <vetrivel.bksys@gmail.com>:
> I have downloaded perl and ruby program in net.I run both the

choose the right tool for a job!

If i had a programming task which needs special attention to speed
and/or security i would choose Ada and not Ruby.

On the other hand i have written a Ruby program which uploads pictures
to several stock photo sites. In this program it is almost completely
useless to optimize for a maximum speed of the program itself because
the bottleneck is the uploading of the pictures and some manual
editing of the pictures at the website. In this case i don't care if
the rotation of a single picture take some seconds more in Ruby, so i
took Ruby because it was more fun to write the program in Ruby.

-Thomas
46a8ebdfabc2485407f89a2db5bdafb7?d=identicon&s=25 Igor Pirnovar (rooby)
on 2009-02-08 00:08
William James wrote:
> Vetrivel Vetrivel wrote:
> Don't indent so deeply.  It makes the code much harder to read.
>
> Don't write a mandelbrot program in an interpreted language.
> Write it in a compiled language like OCaml.

OCaml, Ada, C, C#, Perl, French ... I think all of these things are
rather misplaced here. Isn't this about Ruby? The fact is that one needs
to choose a language that best meets their project requirements,
however, it does not seem  that Vetrivel was searching for a language,
he was not happy with Ruby performance, full stop! He more likely is
searching for answers in general, and he as also some who responded, do
not quite understand what are the drawbacks and what are the true
benefits of using such a powerful tool as Ruby. Ruby is setting the
standards of contemporary computing. C#, which is in many ways a clone
of Ruby is evidently is a prominent proof of this. Still, nothing comes
close to the simplicity, elegance, power and indeed the overall
performance and primarily the productivity of designers and programmers
that work with Ruby.
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-08 00:10
(Received via mailing list)
William James wrote:

> >
> >                                 i = iterate(x/40.0,y/40.0)
>
> Don't indent so deeply.  It makes the code much harder to read.
>
> Don't write a mandelbrot program in an interpreted language.
> Write it in a compiled language like OCaml.

OCaml:

let bailout = 16.0
let max_iterations = 1000

let iterate x y =
  let cr = y -. 0.5  and
      ci = x  and
      zi = 0.0  and
      zr = 0.0  in
  let rec iterate2 zi zr i =
    if i > max_iterations then
      0
    else
      let temp = zr *. zi  and
        zr2 = zr *. zr  and
        zi2 = zi *. zi  in
      if zi2 +. zr2 > bailout then
        i
      else
        iterate2 (temp +. temp +. ci) (zr2 -. zi2 +. cr) (i + 1)
  in
  iterate2 zi zr 1

let mandelbrot =
  for y = -39 to 38 do
    print_endline "";
    for x = -39 to 38 do
      let i = iterate
        (float_of_int x /. 40.0) (float_of_int y /. 40.0) in
      print_string ( if 0 = i then "*" else " " )
    done
  done


let _ = mandelbrot
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-08 00:25
(Received via mailing list)
Igor Pirnovar wrote:

> William James wrote:
> > Vetrivel Vetrivel wrote:
> > Don't indent so deeply.  It makes the code much harder to read.
> >
> > Don't write a mandelbrot program in an interpreted language.
> > Write it in a compiled language like OCaml.
>
> OCaml, Ada, C, C#, Perl, French ... I think all of these things are
> rather misplaced here. Isn't this about Ruby? The fact is that one
> needs to choose a language that best meets their

"one" is singular, so it's "best meets his".

> designers and programmers that work with Ruby.
Don't preach to the choir.  Ruby is my favorite language.
Not even Matz would tell you to use it for mandelbrot programs.
46a8ebdfabc2485407f89a2db5bdafb7?d=identicon&s=25 Igor Pirnovar (rooby)
on 2009-02-08 00:29
William James wrote:
> William James wrote:

> OCaml:
>
> let bailout = 16.0
> let max_iterations = 1000
>
> let iterate x y =
>   let cr = y -. 0.5  and
>       ci = x  and
>       zi = 0.0  and
As I said, rather misplaced discussion. This is about Ruby, not about
some obscure X-sharps which all to us look like the old spaghetti code
from 40 or so years ago when structured techniques became popular after
Pascal bursted into the scene. As for the indentation, Vetrivel clearly
has just discovered vi and Unix clones, where tab is the most prominent
feature. Almost all modern source code editors today implement
GtkSourceView widget library, which manages indentation much more
efficiently than half a century old tools, newly discovered by M$
computer illiterate folks. Lets stop babbling about various screw-sharps
and concentrate on educating newcomers about Ruby!
48721861825d808ee461191c308a6861?d=identicon&s=25 Nico Bonada (nicooo)
on 2009-02-08 02:24
William James wrote:
> Igor Pirnovar wrote:
>
>> William James wrote:
>> > Vetrivel Vetrivel wrote:
>> > Don't indent so deeply.  It makes the code much harder to read.
>> >
>> > Don't write a mandelbrot program in an interpreted language.
>> > Write it in a compiled language like OCaml.
>>
>> OCaml, Ada, C, C#, Perl, French ... I think all of these things are
>> rather misplaced here. Isn't this about Ruby? The fact is that one
>> needs to choose a language that best meets their
>
> "one" is singular, so it's "best meets his".
>

http://en.wikipedia.org/wiki/Singular_they#Generic_they
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2009-02-08 05:51
(Received via mailing list)
Doesn't ruby 1.9 rub faster?

Blog: http://random8.zenunit.com/
Learn rails: http://sensei.zenunit.com/
91e1fb8bd265b7629491ab64c42f0906?d=identicon&s=25 Reid Thompson (Guest)
on 2009-02-08 07:14
(Received via mailing list)
Rados³aw Bu³at wrote:
> http://www.timestretch.com/FractalBenchmark.html ?
>
> Try it with ruby1.9.1. I get about 1.90s for perl and 2.80s for
> ruby1.9.1 so it's not bad.

running on core2 duo gentoo

Ruby Elapsed 0.045477

rthompso@raker ~ $ ruby mand.rb
Rendering

                                        *
                                        *
                                        *
                                        *
                                        *
                                       ***
                                      *****
                                      *****
                                       ***
                                        *
                                    *********
                                  *************
                                 ***************
                              *********************
                              *********************
                               *******************
                               *******************
                               *******************
                               *******************
                             ***********************
                               *******************
                               *******************
                              *********************
                               *******************
                               *******************
                                *****************
                                 ***************
                                  *************
                                    *********
                                        *
                                 ***************
                             ***********************
                          * ************************* *
                          *****************************
                       * ******************************* *
                        *********************************
                       ***********************************
                     ***************************************
                *** ***************************************** ***
                *************************************************
                 ***********************************************
                  *********************************************
                  *********************************************
                 ***********************************************
                 ***********************************************
               ***************************************************
                *************************************************
                *************************************************
               ***************************************************
               ***************************************************
          *    ***************************************************    *
        *****  ***************************************************
*****
        ****** ***************************************************
******
       ******* ***************************************************
*******
     ***********************************************************************
     ********* ***************************************************
*********
        ****** ***************************************************
******
        *****  ***************************************************
*****
               ***************************************************
               ***************************************************
               ***************************************************
               ***************************************************
                *************************************************
                *************************************************
               ***************************************************
                 ***********************************************
                 ***********************************************
                   *******************************************
                    *****************************************
                  *********************************************
                 **** ****************** ****************** ****
                  ***  ****************   ****************  ***
                   *    **************     **************    *
                          ***********       ***********
                          **  *****           *****  **
                           *   *                 *   *


Ruby Elapsed 0.045477
91e1fb8bd265b7629491ab64c42f0906?d=identicon&s=25 Reid Thompson (Guest)
on 2009-02-08 07:16
(Received via mailing list)
Reid Thompson wrote:
>
> Ruby Elapsed 0.045477
>
>
#!/usr/local/bin/ruby

require 'rubygems'
require 'inline'

BAILOUT = 16
MAX_ITERATIONS = 1000

class Mandelbrot

     def initialize
         puts "Rendering"
         for y in -39...39 do
             puts
             for x in -39...39 do
                 i = iterate(x/40.0,y/40.0)
                 if (i == 0)
                     print "*"
                 else
                     print " "
                 end
             end
         end
     end

     inline do |builder|
         builder.c "
         int iterate (double x, double y)
         {
             int BAILOUT = 16;
             int MAX_ITERATIONS = 1000;
             double cr = y-0.5;
             double ci = x;
             double zi = 0.0;
             double zr = 0.0;
             double zr2 = 0.0;
             double zi2 = 0.0;
             int i = 0;
             double temp = 0.0;

             while (1)
             {
                i += 1;
                temp = zr * zi;
                zr2 = zr * zr;
                zi2 = zi * zi;
                zr = zr2 - zi2 + cr;
                zi = temp + temp + ci;

                if ( zi2 + zr2 > BAILOUT)
                {
                    return i;
                }
                if ( i > MAX_ITERATIONS)
                {
                    return 0;
                }
             }
         }"
     end
#    def iterate(x,y)
#        cr = y-0.5
#        ci = x
#        zi = 0.0  while(1)
#        i += 1
#        temp = zr * zi
#        zr2 = zr * zr
#        zi2 = zi * zi
#        zr = zr2 - zi2 + cr
#        zi = temp + temp + ci
#        return i if (zi2 + zr2 > BAILOUT)
#        return 0 if (i > MAX_ITERATIONS)
#    end

end


time = Time.now
Mandelbrot.new
puts
puts "Ruby Elapsed %f" % (Time.now - time)
F065301eb65a5d0da8edcb8de9d5e28e?d=identicon&s=25 Tim Greer (Guest)
on 2009-02-08 07:40
(Received via mailing list)
Julian Leviston wrote:

> Doesn't ruby 1.9 rub faster?
>

Not for that functionality comparing the two languages.
42773b24e0c3fb506a8a875c058a9dd7?d=identicon&s=25 Dylan Evans (Guest)
on 2009-02-08 12:55
(Received via mailing list)
On Sat, Feb 7, 2009 at 11:35 PM, Vetrivel Vetrivel
<vetrivel.bksys@gmail.com
> wrote:

> I have downloaded perl and ruby program in net.I run both the
> programs.But the Ruby program performance very wost than perl.Can any
> one tell me the reasons and
> soultion to make ruby as faster than perl.
> I have attached perl program.
>
>
It's a tortoise and the hare debate really. As a C programmer i can say
that
ruby is rubbish, and yet when i use it i save countless hours of
debugging
and writing kludge code (When you start doing OO in C it's time to try
something new). For me it's the difference between actual productivity
and
abandoning projects because i don't have time, besides i might as well
chew
up some of the idle cycles my shiny new processor always seems to have.
Oh, and despite what some people might say every language has some
merit.
(except cobol)
Aaca034456897ccbc8bb14953c4a41c1?d=identicon&s=25 Radosław Bułat (radarek)
on 2009-02-08 13:43
(Received via mailing list)
2009/2/8 Reid Thompson <reid.thompson@ateb.com>:
>
I don't believe you :P. Show us the code. Did you use RubyInline or
something?:)


--
Pozdrawiam

Rados³aw Bu³at
http://radarek.jogger.pl - mój blog
91e1fb8bd265b7629491ab64c42f0906?d=identicon&s=25 Reid Thompson (Guest)
on 2009-02-08 14:55
(Received via mailing list)
Rados³aw Bu³at wrote:
>>
>>
>
> I don't believe you :P. Show us the code. Did you use RubyInline or something?:)
>
>

see post from 1:14 am --- rubyinline
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2009-02-08 16:11
(Received via mailing list)
You could also look into The project to concert ruby to obj-c which is
compiled. Am I dreaming? I can't remember the name

Blog: http://random8.zenunit.com/
Learn rails: http://sensei.zenunit.com/
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2009-02-08 20:52
(Received via mailing list)
Radosław Bułat wrote:
> On Sat, Feb 7, 2009 at 3:42 PM, Peter Hickman <peterhi@ntlworld.com> wrote:
>> Haven't tried it under JRuby though, you might experience better performance
>> there.
>>
>
> JRuby is faster than 1.9 even without warming. ~2s for jruby, ~2.8s
> for ruby1.9.1. With warm up it goes down to ~1.2s and with --fast flag
> to ~0.75s.

Nice :)

- Charlie
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-09 03:19
(Received via mailing list)
On Sun, Feb 08, 2009 at 03:22:20AM +0900, Igor Pirnovar wrote:
> cycle, and indeed to the complexity of the project. Mere execution time
> of an application represents only a tiny fraction of what is truly
> measured when comparing procedural language like Perl and object
> oriented Ruby. If you compare the two languages in this respect Perl
> doesn't come even close to where Ruby stands. In fact I believe if you
> look at performance issues from this angle, Ruby stands out very proudly
> as the best performing programming language of all times.

You talk as though Perl were something like Java or C++.  It's not.

Development can be incredibly fast with Perl.  It's just suited to
different environments and tasks than Ruby.

For the most part, it's ridiculous to talk about which language's
implementation is faster, in and of itself.  The only time runtime
performance really matters that much is when you have a specific task
for
which run time performance is of great specific importance -- and, even
at those times, a better algorithm is usually worth a lot more
performance gain than a faster language implementation.  Because of
this,
I agree that runtime performance should never be the sole determinant
when choosing which language to use for a given project.  In many cases,
any language in widespread use is going to be fast enough for your
needs,
and as such runtime performance should be somewhere near the *bottom* of
the list of criteria.

. . . but I really don't agree with your assessment of Perl's
development
cycle as something that "doesn't even come close" to Ruby's.
Furthermore, pigeonholing Perl as a "procedural" language is as unfair
to
it as pigeonholing Ruby as "object oriented" is to Ruby.  Both of them
have a lot more to offer.  Both provide excellent support for many
traditionally functional paradigm programming; both support object
oriented development; both can be used in a structured, procedural style
when that's the appropriate technique to employ.

In general, I enjoy programming in Ruby more, these days -- but there
are
tasks for which I'd much rather write the code in Perl than in Ruby.
Each has its strengths, and each has its place in my development toolkit
(and neither of them is clearly "faster" in terms of "the entire project
life cycle", especially considering that different projects have very
different lifecycles).
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-09 14:25
(Received via mailing list)
Chad, I generally agree, however...

2009/2/9 Chad Perrin <perrin@apotheon.com>:
> . . . but I really don't agree with your assessment of Perl's development
> cycle as something that "doesn't even come close" to Ruby's.
> Furthermore, pigeonholing Perl as a "procedural" language is as unfair to
> it as pigeonholing Ruby as "object oriented" is to Ruby.  Both of them
> have a lot more to offer.  Both provide excellent support for many
> traditionally functional paradigm programming; both support object
> oriented development;

... that statement makes me itch.  I try to avoid voicing extreme
opinions, but in this case I have to say: Perl's OO is a bad joke.
Yes, you can program OO style in Perl and there is /some/ support for
this - but it does not really give you much advantage over doing OO in
C (yes, you can do that: even std libraries do it, see open and fopen
et al).

> both can be used in a structured, procedural style
> when that's the appropriate technique to employ.

Right.

> In general, I enjoy programming in Ruby more, these days -- but there are
> tasks for which I'd much rather write the code in Perl than in Ruby.
> Each has its strengths, and each has its place in my development toolkit
> (and neither of them is clearly "faster" in terms of "the entire project
> life cycle", especially considering that different projects have very
> different lifecycles).

IMHO the best arguments for Perl are these
- often it's installed on a *nix system
- CPAN

Kind regards

robert
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-09 19:17
(Received via mailing list)
Robert Klemme wrote:
> Yes, you can program OO style in Perl and there is /some/ support for
> this - but it does not really give you much advantage over doing OO in
> C (yes, you can do that: even std libraries do it, see open and fopen
> et al).
>

I haven't done enough C to say for sure, but I loved Perl's OO. There
definitely seems to be more there -- inheritance via @ISA, constructors
via bless -- and while some find it ugly to expose all the
underpinnings, that is one thing I love about Perl.

It's also one of the same reasons I love Ruby -- I don't have to get my
hands dirty.

Take the simplest example, a method. In Ruby, it'd be:

class  Foo
  def bar(arg)
    ...
  end
end

In Perl (and forgive my syntax, it's rusty), it'd be something like:

package Foo;
sub bar {
  my ($self, $arg) = @_;
  ...
}

Now, the Ruby version is much more readable to me, and much easier to
work with. But there is something magical about the way the Perl version
starts from even more basic primitives. Arguments are simply passed in
as an array, which you can either unpack or not, as you like. The
current object is passed in as an argument, meaning this is just another
subroutine -- it lets you do tricks like this:

my $foo_like_thing = Bar::new();
Foo::bar($foo_like_thing, $some_other_arg);

Kind of like Javascript's call() and apply() -- and I'm not even sure
this can be done in Ruby. For all the duck typing goodness, I can't seem
to figure out how you'd unbind a method and rebind it to something of an
unrelated class, unless there's an explicit tree of inheritance.

Not that this is something I've often (ever?) felt the need to do in
Ruby. I'm just using it to illustrate what I like about Perl -- that
it's so completely relaxed about this kind of thing. It gives you the
bare bones of what's necessary for an object system, and you build
whatever you want on top of it -- even with the guts exposed all over
the place.

> IMHO the best arguments for Perl are these
> - often it's installed on a *nix system
> - CPAN

I'll agree with that. And for new projects, I will instinctively choose
Ruby. But it's for other reasons -- I like Ruby's syntax, and I like
everything being an object, and being able to do things like the Rails
Object#blank? hack, and iterators, and...
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-09 21:52
(Received via mailing list)
On 09.02.2009 19:15, David Masover wrote:
> Robert Klemme wrote:
>> Yes, you can program OO style in Perl and there is /some/ support for
>> this - but it does not really give you much advantage over doing OO in
>> C (yes, you can do that: even std libraries do it, see open and fopen
>> et al).
>
> I haven't done enough C to say for sure, but I loved Perl's OO. There
> definitely seems to be more there -- inheritance via @ISA, constructors
> via bless -- and while some find it ugly to expose all the
> underpinnings, that is one thing I love about Perl.

It's not that I find it "ugly".  It's more that I find it hard to read
and remember whichever you have to do to get a class, inheritance,
methods, data members etc.  IMHO Perl makes OO unnecessary hard.  There
is a paper written by Larry Wall about the flaws of Perl's OO which I
cannot seem to find right now.

> It's also one of the same reasons I love Ruby -- I don't have to get my
> hands dirty.

"Same reason"?  That sounds strange to me.

> package Foo;
> sub bar {
>   my ($self, $arg) = @_;
>   ...
> }
>
> Now, the Ruby version is much more readable to me, and much easier to
> work with.

Exactly!

> But there is something magical about the way the Perl version
> starts from even more basic primitives.

Frankly, I don't like magic in programming - at least not the kind of
magic that makes it hard to follow a program when reading it.  I have
had to maintain too much cryptic code to not highly appreciate
readability.

> Arguments are simply passed in
> as an array, which you can either unpack or not, as you like.

You can do that in Ruby as well.  Just do

def initialize(*a)
   what, ever, you_like = a
end

> The
> current object is passed in as an argument, meaning this is just another
> subroutine -- it lets you do tricks like this:
>
> my $foo_like_thing = Bar::new();
> Foo::bar($foo_like_thing, $some_other_arg);

What does this?  Does it create a Bar and then initializes it as Foo?
What do we gain from that?  Where is the advantage over declaring
classes Foo and Bar and making Bar a subclass of Foo if they are so
closely related?  (Or use a module for that matter)

> Kind of like Javascript's call() and apply() -- and I'm not even sure
> this can be done in Ruby. For all the duck typing goodness, I can't seem
> to figure out how you'd unbind a method and rebind it to something of an
> unrelated class, unless there's an explicit tree of inheritance.

Why would you want to do that?  There's a reason why both classes are
unlrelated, i.e. chances are that the method would not work in the other
class / object.  If you want to simply share code then you can use
modules which is a much cleaner and safer way to do it.

> Not that this is something I've often (ever?) felt the need to do in
> Ruby. I'm just using it to illustrate what I like about Perl -- that
> it's so completely relaxed about this kind of thing. It gives you the
> bare bones of what's necessary for an object system, and you build
> whatever you want on top of it -- even with the guts exposed all over
> the place.

The problem with this is: you _have_ to build it yourself.  If I only
get the basic building blocks and have to reapply them over and over
again to get the same result (a bunch of classes with methods and state)
then I am wasting time.  A genuine object oriented language is much
superior.

Kind regards

  robert
46a8ebdfabc2485407f89a2db5bdafb7?d=identicon&s=25 Igor Pirnovar (rooby)
on 2009-02-09 22:35
Chad Perrin wrote:

> . . .
> You talk as though Perl were something like Java or C++.  It's not.
> . . .
I am saying nothing of that kind!?

The fact that you are lumping Perl together with C++ and Java or Ruby
for that matter speaks volumes, and I simply do not have time to debate
this. But I can not allow myself not to reiterate that Perl is a
procedural language, and that its OO capabilities do not impress me at
all. OO in Perl is worse than C's GNOME extension. To use OOP in Perl is
just not worth the trouble. I also love Perl but not for it's OOP but
rather that for which it was designed in the first place,  which is
procedural stuff and efficient shell programming that is almost as
powerful as C. However, there are times when even Perl is too convoluted
and a simple Unix shell script will do much better. At the same token I
believe, that to use Ruby as a replacement for shell script as many use
Perl, is a brain damaging proposition. The bottom line is Ruby is an
OOPL and is the most powerful in this domain. With Ruby, scripting is
just an additional bonus, and is not at all what it was designed for.
Arguably Ruby is one of The Best OOPLs, and as I have already said
nothing so far comes close to it, let alone  Perl which is nothing more
than super duper scripting language, with a bonus to wrap  it in a
reasonable OO paradigm, which, by the way, is rather poorly understood
by those who use Perl the most.

Using Perl on large projects is no longer a desirable enterprise, though
in the past it used to be a knockout when it competed with C. With the
advent of OO, Perl had to be tweaked to provide this alternative,
however that alternative sucks, and that is why Python took over its
domain. Thankfully, Ruby was born to replace these OO concoctions that I
cherish only as interesting OO fossils. On the other hand, what is good
and healthy lives long, and I believe procedural Perl will never die.
Though with some effort you can do anything you could do in Perl also in
Ruby. But isn't that true for all programming languages. This is known
since the 60's when COBOL programs were sprinkled with Assembler
procedures.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-09 23:25
(Received via mailing list)
Robert Klemme wrote:
>> the underpinnings, that is one thing I love about Perl.
>
> IMHO Perl makes OO unnecessary hard.

Very true. Most CPAN modules manage it anyway, these days, but I agree
-- OO doesn't have to be that hard.

It is fun, though.

>> It's also one of the same reasons I love Ruby -- I don't have to get
>> my hands dirty.
>
> "Same reason"?  That sounds strange to me.

I love Ruby because I don't have to get my hands dirty. I love Perl
because I'm always getting my hands dirty, pretty much out of necessity.

It's something that's unique to each, and something that I love about
each, under different circumstances.

>> Arguments are simply passed in as an array, which you can either
>> unpack or not, as you like.
>
> You can do that in Ruby as well.

Yes, I understand. However, if you look at your example:

> def initialize(*a)
>   what, ever, you_like = a

You're still explicitly accepting one positional argument -- it just
happens to be the magical one that instead matches "zero or more of the
remaining positional arguments".

For the same reason, I also find it kind of cool that Perl objects are
typically just hashes with methods attached. Ruby objects, while
effectively the same thing, tend to hide instance variables away. I like
that, it's a cleaner approach, but it is still fun to take a hash of
options, perhaps filter them, and then bless them as an object.

Occasionally, this actually is more convenient. For instance, in Ruby, I
too often find myself writing code like this:

class Foo
  attr_reader :some, :random, :args
  def initialize some, random, args
    @some = some
    @random = random
    @args = args
  end
end

Or worse, let's say I don't like positional arguments (and I don't):

class Foo
  attr_reader :some, :random, :args
  def initialize options
    @some = options[:some]
    @random = options[:random]
    @args = options[:args]
  end
end

Or worse, say I've written some setters that do something magical. I
then want to set those if they've been passed in:

class Foo
  attr_reader :some, :random, :args
  def initialize options
    self.some = options[:some] unless options[:some].nil?
    self.random = options[:random] if options[:random].nil?
    self.args = options[:args] if options[:args].nil?
  end
end

Yes, I could do some metaprogramming. I should stress that I do prefer
Ruby to Perl, for exactly that reason -- if this ever gets too annoying,
I can probably do something like the following, which has probably
already been done somewhere:

module AutoInitializer
  def self.included klass
    klass.extend ClassMethods
  end
  module ClassMethods
    def auto_init *args
      include(Module.new do
        attr_accessor *args
        define_method :initialize do |options|
          args.each do |arg|
            if options.has_key? arg
              self.send "#{arg}=", options[arg]
            end
          end
        end
      end)
    end
  end
end

Now my class is only this:

class Foo
  include AutoInitializer
  auto_init :some, :random, :args
end

That's arguably better, but a bit more work at the beginning. Still,
it's worth comparing to the Perl solution:

sub init {
  my($class, $self) = @_;
  bless $self => $class;
}

Granted, there are better ways to do that. It's certainly going to get
hairier if there are going to be setters involved. But that is one of
the fun side effects of what, at first, seams like a haphazard,
tacked-on design.

JavaScript is similar, in some respects. Suppose someone passes me in a
hash of options. Well, hashes are objects, so I can just do this:

function Foo(obj) {
  for (var property in obj) {
    this[property] = obj[property]
  }
};

Bam. Not only instant options, but instant extensibility -- nothing
prevents a user from passing in a function to override one of mine, thus
creating a singleton descendant of my class.

I'm going to stop now, because this is getting a bit long, and the core
point hasn't changed -- I like Ruby, and I see how this kind of stuff
can be done in Ruby, but I wouldn't immediately dismiss these other
object systems.
>>
>> my $foo_like_thing = Bar::new();
>> Foo::bar($foo_like_thing, $some_other_arg);
> The current object is passed in as an argument, meaning this is just
> another subroutine -- it lets you do tricks like this:
>
> What does this?  Does it create a Bar and then initializes it as Foo?

No, it creates a Bar, and calls Foo's bar method on it, if I've gotten
the syntax right.

>> Kind of like Javascript's call() and apply() -- and I'm not even sure
>> this can be done in Ruby. For all the duck typing goodness, I can't
>> seem to figure out how you'd unbind a method and rebind it to
>> something of an unrelated class, unless there's an explicit tree of
>> inheritance.
>
> Why would you want to do that?  There's a reason why both classes are
> unlrelated, i.e. chances are that the method would not work in the
> other class / object.  If you want to simply share code then you can
> use modules which is a much cleaner and safer way to do it.

Indeed, modules are usually the saner choice. However, I have done this
_often_ in Javascript. Probably the simplest example might be the common
each loop:

function each(array, func) {
  for (var i in array) {
    func.call(array[i], i);
  }
}
each(['one','two','three'], function(i) {
  // now 'this' is bound to the value
});

Granted, that's a toy, but it is more convenient that way. And then
there are the cases where you want to do something clever -- say you
have multiple superclasses:

var Bar = {
  // one big pile of funcitons
}
var Super = {
  // another big pile of functions
}
obj.foo = function() {
  if (i_want_super) {
    Super.bar.apply(this, arguments);
  } else {
    Bar.foo.apply(this, arguments);
  }
}

Maybe some of those are actually superclasses. Maybe they're modules,
and you only need a single method, not the whole module.

Either way, I would put the burden back on you. Why is this so
dangerous? Why is it any more dangerous than the other duck typing
tricks Rubyists use every day? Why shouldn't I be able to do:

a.method(:foo).unbind.bind(b)

when a and b aren't related, but I happen to know they share a common
theme? After all, what ties the method to the object -- isn't it mostly
going to be calling instance methods, and occasionally accessing
instance variables -- so why should 'self' be exempted from the "quacks
like" rule?

> The problem with this is: you _have_ to build it yourself.  If I only
> get the basic building blocks and have to reapply them over and over
> again to get the same result (a bunch of classes with methods and
> state) then I am wasting time.

And then you discover one of the most basic tools in any language: A
library.

Take my above AutoInitializer example. I could complain that I have to
reinvent it every time, but clearly I don't. I can just file it away in
a file called autoinit.rb, and if it turns out to be original, I can
upload a gem.

Or I can decide to use openstruct instead.

What matters is how powerful those basic building blocks are, and what
it looks like when you're finished.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-10 17:55
(Received via mailing list)
2009/2/9 David Masover <ninja@slaphack.com>:
> Robert Klemme wrote:
>> IMHO Perl makes OO unnecessary hard.
>
> Very true. Most CPAN modules manage it anyway, these days, but I agree -- OO
> doesn't have to be that hard.
>
> It is fun, though.

Well, everybody as they like. :-)

>  attr_reader :some, :random, :args
>  def initialize some, random, args
>   @some = some
>   @random = random
>   @args = args
>  end
> end

Then you probably haven't used Struct enough. For me the code above is
just

Foo = Struct.new :some, :random, :args

> Or worse, let's say I don't like positional arguments (and I don't):
>
> class Foo
>  attr_reader :some, :random, :args
>  def initialize options
>   @some = options[:some]
>   @random = options[:random]
>   @args = options[:args]
>  end
> end

Foo = Struct.new :some, :random, :args do
  def initialize(options)
    members.each {|m| self[m] = options[m]}
  end
end

> end
Foo = Struct.new :some, :random, :args do
  def initialize(options)
    members.each {|m| x = options[m] and self[m] = x}
  end
end

>   def auto_init *args
>   end
>  end
> end

This is not needed as I have tried to show above.

> sub init {
>  my($class, $self) = @_;
>  bless $self => $class;
> }

But this does not set properties, does it? (My Perl is a bit rusty
nowadays.)  If this is the case then this is not a solution to the
same problem.

> Granted, there are better ways to do that. It's certainly going to get
> hairier if there are going to be setters involved. But that is one of the
> fun side effects of what, at first, seams like a haphazard, tacked-on
> design.

Ok, *I* do not get fun from this - especially when I have to do it
over and over again...

> a user from passing in a function to override one of mine, thus creating a
> singleton descendant of my class.

-> OpenStruct

>> What does this?  Does it create a Bar and then initializes it as Foo?
>
> No, it creates a Bar, and calls Foo's bar method on it, if I've gotten the
> syntax right.

*if* - LOL  If even _you_ do not know...

> Indeed, modules are usually the saner choice. However, I have done this
> });
>
> Granted, that's a toy, but it is more convenient that way.

And in Ruby it's already built in.

> obj.foo = function() {
>  if (i_want_super) {
>   Super.bar.apply(this, arguments);
>  } else {
>   Bar.foo.apply(this, arguments);
>  }
> }
>
> Maybe some of those are actually superclasses. Maybe they're modules, and
> you only need a single method, not the whole module.

If you need a single method only that should go into its own module.
Otherwise there's something wrong with how code is packaged IMHO.

> Either way, I would put the burden back on you. Why is this so dangerous?
> Why is it any more dangerous than the other duck typing tricks Rubyists use
> every day?

Because in Ruby hackery (or call it "metaprogramming") is an add on,
i.e. you can use it in special situations, while in Perl you need to
do it to get basic things (OO) to work.

> Why shouldn't I be able to do:
>
> a.method(:foo).unbind.bind(b)
>
> when a and b aren't related, but I happen to know they share a common theme?

Because this is an indication that your code is not well structured.
If they share a "common theme" this theme could be packaged into a
module and properly documented.  Just moving one method over is an ad
hoc solution which - when applied with only moderate frequency - will
give unreadable and thus unmaintainable code very soon.

> After all, what ties the method to the object -- isn't it mostly going to be
> calling instance methods, and occasionally accessing instance variables --
> so why should 'self' be exempted from the "quacks like" rule?

If you need only this single method you can as well use a functional
approach, just define

def foo(obj)
  obj.instance_method_a = 1
  obj.another_method
end

No need for unbind bind hackery.

>> The problem with this is: you _have_ to build it yourself.  If I only get
>> the basic building blocks and have to reapply them over and over again to
>> get the same result (a bunch of classes with methods and state) then I am
>> wasting time.
>
> And then you discover one of the most basic tools in any language: A
> library.

Even better: have it already in the standard library or language.
Even if it's on CPAN already, you still need to add this other
external module to your project etc.  You can't save Perl's OO that
way.

> Take my above AutoInitializer example. I could complain that I have to
> reinvent it every time, but clearly I don't. I can just file it away in a
> file called autoinit.rb, and if it turns out to be original, I can upload a
> gem.
>
> Or I can decide to use openstruct instead.
>
> What matters is how powerful those basic building blocks are, and what it
> looks like when you're finished.

It matters because you might take longer because you need to first
build complex structures out of your basic building blocks because
they are not present in the language.  It matters because some poor
maintainer has to read all the code and understand in order to apply
his changes.

Why should I choose a language with broken OO when I want to do OO if
I can have one with good OO, a marvelous clean syntax which has
similar other capabilities (scripted, dynamic, built in regular
expressions etc.)?  If this is fun for you then be it.  But please do
not try to sell me Perl's OO as a great thing - because it isn't.

Cheers

robert
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-10 19:32
(Received via mailing list)
On Mon, Feb 9, 2009 at 7:15 PM, David Masover <ninja@slaphack.com>
wrote:
<snip>
>
> I haven't done enough C to say for sure, but I loved Perl's OO. There
> definitely seems to be more there -- inheritance via @ISA, constructors via
> bless -- and while some find it ugly to expose all the underpinnings, that
> is one thing I love about Perl.

Are you aware that Perl's MI via @ISA is probably the worst way one
can implement MI in?
That said I admit that one can write nice OO code in Perl with some
discipline.

Cheers
Robert
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-10 19:44
(Received via mailing list)
Robert Klemme wrote:
> Then you probably haven't used Struct enough. For me the code above is
> just
> Foo = Struct.new :some, :random, :args
>

Ah, thanks. That should help.

>> That's arguably better, but a bit more work at the beginning. Still, it's
>> worth comparing to the Perl solution:
>>
>> sub init {
>>  my($class, $self) = @_;
>>  bless $self => $class;
>> }
>>
>
> But this does not set properties, does it?

It does, actually, assuming you called it with a hash of options. Perl
objects are most commonly a blessed hash.

Granted, you'd probably want to do a bit more sanity checking -- the
above won't complain if you pass a string instead of a hash, or if you
misspell an argument, etc.

What it doesn't solve is the part where you'd use setters -- it's the
equivalent of directly setting the instance variables.

>>
>> Bam. Not only instant options, but instant extensibility -- nothing prevents
>> a user from passing in a function to override one of mine, thus creating a
>> singleton descendant of my class.
>>
>
> -> OpenStruct
>

Maybe I should read the docs, but as I understand it, in Javascript, I
can do this:

f = Foo({
  a: 'some_string',
  b: 12345,
  c: function() {
    // some method
  }
});

I could even do:

f = Foo(new Bar());

thus creating a spontaneous new child of both Foo and Bar. Keep in mind
that both Foo and Bar are classes, each of which may have methods of
their own -- in this case, Bar's methods (or properties) override Foo's.

To get something even close in Ruby, I'd have to do this:

f = OpenStruct.new
class << f
  def c
    #some method
  end
end

And the other example would look more like this -- but only if Bar was a
module, and not a class in its own right:

f = Foo.new
f.extend Bar

And, since it must be a module, it's not really the same thing. Again,
this could be faked with something elaborate:

class Foo
  def initialize(klass)
    meta = class << self; self; end
    obj = klass.new
    obj.methods.each do |method|
      meta.class_eval do
        define_method method do |*args, &block|
          obj.send method, *args, &block
        end
      end
    end
  end
end

Note that a subclass of Delegator won't work here (if it had a chance?),
as that would have Foo override Bar, not vice versa. And even this
doesn't do what we want, as rather than including methods of both
classes in a kind of poor-man's multi-inheritance, we're in fact
delegating to another object.

>> No, it creates a Bar, and calls Foo's bar method on it, if I've gotten the
>> syntax right.
>>
>
> *if* - LOL  If even _you_ do not know...
>

I haven't touched Perl in any meaningful way in over a year. When I took
a break from Ruby for that long, it took awhile for me to get fluent and
sure of my Ruby syntax, also.

>> Maybe some of those are actually superclasses. Maybe they're modules, and
>> you only need a single method, not the whole module.
>>
>
> If you need a single method only that should go into its own module.
>

One method per module! Great idea.

Doing a functional approach is better, but still missing the point.

The point is that the person packaging the code might not know ahead of
time that you need that method, or that it's a useful method to extract
on its own. That leaves you with a choice of either patching their code
(best long term approach), or copying and pasting, or doing some
_really_ crude hacks, if it's even possible.

> Otherwise there's something wrong with how code is packaged IMHO.
>

Probably. But for the same reason I like being able to monkeypatch Ruby
classes, I also like being able to hack Javascript in this way. It means
I can get something working, quickly, without immediately having to dig
into the other code and patch it.

>> Either way, I would put the burden back on you. Why is this so dangerous?
>> Why is it any more dangerous than the other duck typing tricks Rubyists use
>> every day?
>>
>
> Because in Ruby hackery (or call it "metaprogramming") is an add on,
> i.e. you can use it in special situations, while in Perl you need to
> do it to get basic things (OO) to work.
>

There are, however, libraries to make the OO less painful in Perl.

To take a Ruby example, Rails likes to autoload classes and modules by
overriding const_missing. I could argue, then, that you need
const_missing to get basic functionality, that of not having to require
a dozen files at the top of each file. But if I'm working on a Rails
app, it's nicely tucked away for me. When I'm not, I wrote a simpler
version using Kernel#autoload -- autoload isn't sufficient by itself,
but this worked well enough.

And yet, I've provided at least a few places where that metaprogramming
(or hackery) is more difficult than it needs to be in Ruby, or sometimes
flat-out impossible.

No, I don't expect it to be easy -- it probably shouldn't be. But we're
talking about a language where I can have a method reach up the call
stack and evaluate text in the scope of its caller. It's a language
where I can redefine pretty much any operator, on pretty much any class
-- I can make 2+2=5, if I really want. Or I can define nil.nil? to be
false, or Object#nil? to be true, and make the interpreter crash.

Next to all of that, the ability to rebind a method to an unrelated
class seems relatively sane. You could even have UnboundMethod#bind keep
doing what it does, and add an UnboundMethod#bind! to do the more
"dangerous" thing.

>> Why shouldn't I be able to do:
>>
>> a.method(:foo).unbind.bind(b)
>>
>> when a and b aren't related, but I happen to know they share a common theme?
>>
>
> Because this is an indication that your code is not well structured.
> If they share a "common theme" this theme could be packaged into a
> module and properly documented.

Just as, in Java, I shouldn't miss duck typing, because if they're
really related, they should share common ancestry.

> Just moving one method over is an ad
> hoc solution which - when applied with only moderate frequency - will
> give unreadable and thus unmaintainable code very soon.
>

Again, I'm not seeing how this has any more potential for disaster than
duck typing or metaprogramming. Those have as much capacity for misuse.

Now, not doing that often is probably a good idea -- not using
Kernel#eval often might also be a good idea. But I don't like it when a
tool tells me what I may or may not do, simply because it's not a good
idea.

> Even better: have it already in the standard library or language.
> Even if it's on CPAN already, you still need to add this other
> external module to your project etc.

I tend not to build things that don't rely on at least a few external
modules. I would rather have a language flexible enough to build things
like this as an external library, in the language itself, than one that
has everything built in.

In fact, that's one complaint about Perl (or PHP) -- they both have a
lot built in, and a lot polluting the root namespace, for things that
may have once been very common tasks. I believe Perl has finally moved
the report syntax into a different module -- keep in mind, Perl is
called practical extraction and _report_ language, but they decided
reports no longer belong in the core language. I know I'd be (slightly)
happier with PHP if templating wasn't a part of the core language.

> It matters because you might take longer because you need to first
> build complex structures out of your basic building blocks because
> they are not present in the language.

Unless, of course, they're already there on CPAN.

> It matters because some poor
> maintainer has to read all the code and understand in order to apply
> his changes.
>

That's a bit like saying we shouldn't use Rails, because any potential
maintainer will have to learn Rails as well as our own codebase. And
that is somewhat true -- Symbol#to_proc wasn't in core Ruby at the time.
But I think it's reasonable to make the core language smaller, and push
things into frameworks, so long as the syntax doesn't suffer. (That's a
big reason I prefer Ruby -- syntax.)

I'm not trying to sell Perl's OO as the best thing, or even "better".
But I'm defending it as inherently less useful than Ruby's. Someone
might as easily say that Ruby's OO is inherently less useful than
Java's, because Java does stricter (static) type-checking.
46a8ebdfabc2485407f89a2db5bdafb7?d=identicon&s=25 Igor Pirnovar (rooby)
on 2009-02-10 20:21
David Masover wrote:
> Robert Klemme wrote:
>
> I'm not trying to sell Perl's OO as the best thing, or
> even "better". But I'm defending it as inherently less
> useful than Ruby's. Someone might as easily say that
> Ruby's OO is inherently less useful than Java's, because
> Java does stricter (static) type-checking.

Could you be more wrong and further from the truth? Perl can not be
defended as a good OOPL, because it simply is not. It lacks so many
things that what you get by using it is redundancy and more work, the
things that good OO is trying to minimize if not eliminate. Secondly,
what you call lack of type-checking can arguably be considered one of
Ruby's big advantages over those languages that have this feature.
Strictly, from a pragmatical point of view, it makes much more sense
classifying objects based on what they can do rather than to which
"aristocracy" they belong. It is well known fact that Ruby is based on
"meritocracy" and that, semantically and/or philosophically, is
orthogonal to aristocracy! True that OO is all-inclusive and flat with
regards to orthogonal principles, but that makes it dramatically
distinct from pyramid and geriatric hierarchical structures which are
the footprint for all the procedural languages. It takes to much effort
in procedural languages to account for that which they lack!
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-10 21:38
(Received via mailing list)
Igor Pirnovar wrote:
> things that what you get by using it is redundancy and more work, the
> things that good OO is trying to minimize if not eliminate.

Granted...

> what you call lack of type-checking can arguably be considered one of
> Ruby's big advantages over those languages that have this feature.
>

Yes, I realize this. However, you should also realize that both Perl and
Javascript have a few similar features that make Ruby actually stricter
than either. The examples I gave both revolve around the fact that in
Perl and Javascript, functions (or subroutines) are just that. They can
be used as methods, and thus related to an object or a class, but they
are not inherently tied to that object.

In Ruby, however, I can't use a method from one class on a method from
another class, unless the two classes are related. I also can't use a
class as a module. In other words, it's the exact same sort of static
type checking, protect-you-from-yourself mentality as Java.

> Strictly, from a pragmatical point of view, it makes much more sense
> classifying objects based on what they can do rather than to which
> "aristocracy" they belong.

Except that Ruby enforces the aristocracy with respect to which methods
belong to which classes.

> It takes to much effort
> in procedural languages to account for that which they lack!
>

Except Perl is not strictly procedural, and Javascript actually has a
very nice prototypal object system.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-10 22:22
(Received via mailing list)
On Sun, Feb 08, 2009 at 10:23:15AM +0900, Nico Bonada wrote:
> William James wrote:
> >
> > "one" is singular, so it's "best meets his".
> >
>
> http://en.wikipedia.org/wiki/Singular_they#Generic_they

  it is unacceptable to a great many readers either to resort to
  nontraditional gimmicks to avoid the generic masculine (by using
he/she
  or s/he, for example) or to use they as a kind of singular pronoun.

https://secure.wikimedia.org/wikipedia/en/wiki/Singular_they
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-10 22:26
(Received via mailing list)
On Sun, Feb 08, 2009 at 08:28:52AM +0900, Igor Pirnovar wrote:
> and concentrate on educating newcomers about Ruby!
OCaml isn't any "X-sharp" language.  It has decent support for both
functional and object oriented styles, and can in fact do the latter in
significantly fewer (and cleaner) lines of code than C#.

There's nothing about vi(m) that prevents one from using other
indentation schemes than an eight-space tab effectively.  There's
nothing
about GUIness that makes an editor inherently better or more "modern".

If you really think the topic should be limited to Ruby, you might want
to start with taking your own advice, and trying to avoid dragging
editor
flame wars and your uninformed opinions about languages other than Ruby
into the discussion.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-10 22:26
(Received via mailing list)
On Mon, Feb 09, 2009 at 12:09:52AM +0900, Julian Leviston wrote:
> You could also look into The project to concert ruby to obj-c which is
> compiled. Am I dreaming? I can't remember the name

Wait . . . seriously?  I need to find this project.  That sounds like
fun.
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-11 01:45
(Received via mailing list)
Reid Thompson wrote:

> BAILOUT = 16
>                  if (i == 0)
>          int iterate (double x, double y)
>              double temp = 0.0;
>                 if ( zi2 + zr2 > BAILOUT)
>                 {
>                     return i;
>                 }
>                 if ( i > MAX_ITERATIONS)
>                 {
>                     return 0;
>                 }
>              }
>          }"
>      end

>
> end
>
>
> time = Time.now
> Mandelbrot.new
> puts
> puts "Ruby Elapsed %f" % (Time.now - time)


Using the functional language F#:

0.0400575999999999 on my laptop with 2GHz Pentium.

let bailout = 16.0
let max_iterations = 1000


let iterate x y =
  let cr = y - 0.5  and
      ci = x  and
      zi = 0.0  and
      zr = 0.0  in
  let rec loop zi zr i =
    if i > max_iterations then
      0
    else
      let temp = zr * zi  and
        zr2 = zr * zr  and
        zi2 = zi * zi  in
      if zi2 + zr2 > bailout then
        i
      else
        loop (temp + temp + ci) (zr2 - zi2 + cr) (i + 1)
  in
  loop zi zr 1

let mandelbrot () =
  for y = -39 to 38 do
    print_endline "";
    for x = -39 to 38 do
      let i = iterate
        (float x / 40.0) (float y / 40.0) in
      System.Console.Write( ( if 0 = i then "*" else " " ) )
    done
  done


let start_time = Sys.time ()
let _ = mandelbrot ();
print_endline "";
System.Console.Write (Sys.time () - start_time)
91e1fb8bd265b7629491ab64c42f0906?d=identicon&s=25 Reid Thompson (Guest)
on 2009-02-11 01:48
(Received via mailing list)
Chad Perrin wrote:
> On Mon, Feb 09, 2009 at 12:09:52AM +0900, Julian Leviston wrote:
>> You could also look into The project to concert ruby to obj-c which is
>> compiled. Am I dreaming? I can't remember the name
>
> Wait . . . seriously?  I need to find this project.  That sounds like
> fun.
>

i googled, but couldn't find anything -- if you happen to run across it
pls ping
me with the url

thanks,
reid
91e1fb8bd265b7629491ab64c42f0906?d=identicon&s=25 Reid Thompson (Guest)
on 2009-02-11 05:45
(Received via mailing list)
William James wrote:
>>
>>                  i = iterate(x/40.0,y/40.0)
>>          builder.c "
>>              int i = 0;
>>
>>      end
> Using the functional language F#:
>
> 0.0400575999999999 on my laptop with 2GHz Pentium.
>

On same box using all C.
Echo delay is 0s and 20842us -> 20842 microseconds = 0.020842 seconds.
This is
an Intel(R) Core(TM)2 CPU 6320  @ 1.86GHz box w 2GB RAM running gentoo
with
entire system compiled with CFLAGS="-march=prescott -O2 -g -pipe" +
feature
splitdebug ( everything compiled with debug except mandInC ).
-rwxr-xr-x  1 rthompso staff         7104 2009-02-10 23:36 mandInC


time calc code pulled from the web...

rthompso@raker ~ $ cat mandInC.c
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

/**
  * this function is for computing the time difference between timeval x
and y
  * the result is stored in result
  */
int
timeval_subtract (struct timeval *result, struct timeval *x, struct
timeval *y)
{
     /* Perform the carry for the later subtraction by updating y. */
     if (x->tv_usec < y->tv_usec) {
         int nsec = (y->tv_usec - x->tv_usec) / 1000000 + 1;
         y->tv_usec -= 1000000 * nsec;
         y->tv_sec += nsec;
     }
     if (x->tv_usec - y->tv_usec > 1000000) {
         int nsec = (x->tv_usec - y->tv_usec) / 1000000;
         y->tv_usec += 1000000 * nsec;
         y->tv_sec -= nsec;
     }

     /* Compute the time remaining to wait.
     tv_usec is certainly positive. */
     result->tv_sec = x->tv_sec - y->tv_sec;
     result->tv_usec = x->tv_usec - y->tv_usec;

     /* Return 1 if result is negative. */
     return x->tv_sec < y->tv_sec;
}

int iterate (double x, double y)
{
     int BAILOUT = 16;
     int MAX_ITERATIONS = 1000;
     double cr = y-0.5;
     double ci = x;
     double zi = 0.0;
     double zr = 0.0;
     double zr2 = 0.0;
     double zi2 = 0.0;
     int i = 0;
     double temp = 0.0;

     while (1)
     {
         i += 1;
         temp = zr * zi;
         zr2 = zr * zr;
         zi2 = zi * zi;
         zr = zr2 - zi2 + cr;
         zi = temp + temp + ci;

         if ( zi2 + zr2 > BAILOUT)
         {
             return i;
         }
         if ( i > MAX_ITERATIONS)
         {
             return 0;
         }
     }
}

int main()
{
     int y = -39;
     int x = -39;
     int i = -1;
     struct timeval start, stop, echodelay;  // start, stop and echo
delay times

     if((gettimeofday(&start, NULL)) == -1)
     {
         perror("gettimeofday");
         exit(1);
     }
     for (y = -39; y <= 39; ++y)
     {
         printf("\n");
         for (x = -39; x <= 39; ++x)
         {
             i = iterate(x/40.0, y/40.0);
             if (i == 0)
                 printf("*");
             else
                 printf(" ");
         }
     }

     if((gettimeofday(&stop, NULL)) == -1)
     {
         perror("gettimeofday");
         exit(1);
     }
     /* compute time delay */
     timeval_subtract(&echodelay, &stop, &start);

     printf("\nEcho delay is %ds and %dus\n", echodelay.tv_sec,
echodelay.tv_usec);

     return 0;
}
C482081f2c6c893c26f72f6e31999bcb?d=identicon&s=25 Zachary Brown (Guest)
on 2009-02-11 05:54
(Received via mailing list)
On Feb 10, 2009, at 7:45 PM, Reid Thompson wrote:

> thanks,
> reid
>
I could be entirely wrong on this, but http://macruby.org seems to
describe something like what you were looking for?

Just a thought.

-Zac
46a8ebdfabc2485407f89a2db5bdafb7?d=identicon&s=25 Igor Pirnovar (rooby)
on 2009-02-11 07:51
David Masover wrote:

> However, you should also realize that both Perl and
> Javascript have a few similar features that make Ruby actually stricter
> than either.

Similarities exist because Ruby is OOPL, and supports much broader
domain and programming paradigm than that in which and for which Perl
was designed and invented. Ruby is OOPL from the start, and has to be
able to model both geriatric pyramid organizations as well as flat
object organizations. The two indeed are orthogonal. However, OO has not
totally relaxed all the rules and does not promote a kind of anarchy one
could create with JavaScript and Perl.

> The examples I gave both revolve around the fact that in
> Perl and Javascript, functions (or subroutines) are just that. They can
> be used as methods, and thus related to an object or a class, but they
> are not inherently tied to that object.
>
> In Ruby, however, I can't use a method from one class on a method from
> another class, unless the two classes are related. I also can't use a
> class as a module. In other words, it's the exact same sort of static
> type checking, protect-you-from-yourself mentality as Java.

Though the advent of OO enabled us to much better cope with complex,
parallel and concurrent systems all of which are also elements of chaos,
OO itself is not chaotic and does not, as I have already said, promote
anarchy, which you are suggesting. There are rules that have to be
adhered to, only they are much more relaxed than are rules in
hierarchical structured pyramids of structured organizations. OO
organizations are flat and they accept and tolerate orthogonal concepts,
something unimaginable in pyramid structural organizations and
programming. There are rules that govern the freedom of selecting
procedural or structured methods, and when to abide by the orthogonal OO
principles. Failing to understanding these principles leads to chaos and
anarchy. The fact that you see meritocracy in the same light as
aristocracy is one such example of poor understanding of classification
and membership, or inheritance, aggregation, association and delegation
for that matter. In procedural languages you have to enforce these rules
yourself, in OO ideally the language enforces these concepts. Module is
not a class, which is not only true in Ruby but also in the OO bible -
Booch's OOA/D. This can be said for all general OO methodologies. And
lastly, an instance method should not be treated as a loosely defined
function, nor should an object exhibit some foreign behaviour of some
arbitrary function, it totally violates encapsulation. Your propositions
and suggestions translate into total chaos and anarchy, where any
identity could be shared among all members of the universe (read any
domain)!

> Except that Ruby enforces the aristocracy with respect to which methods
> belong to which classes.

You are ignoring the merits on which a pure OO class enforces membership
rights. This unjustly is often seen as  an anthropological attribute
objects have, but many objects are actors and actors are subjects with
responsibilities and behaviours, by which you classify them. You are
pushing aristocracy where it has no place. True there are objects that
only exist to carry a state, and they do have their place in the
universe as passive entities born with a silver spoon in their mouth,
one might say. However, not much would be happening if objects with
behaviour would not exist. Ask yourself, what connotation is ascribed to
the above mentioned property: "born with a silver spoon in your mouth",
and on the other hand what the orthogonal connotation ascribed to the
phrase "well earned" is?

> Except Perl is not strictly procedural, and Javascript actually has a
> very nice prototypal object system.

This is is pure baloney. Perl was designed as such, and OO is only it's
extension - a bonus so to speak,  which becomes a tremendous burden to
the language, and very quickly even larger burden to the developer as
well as the project as it grows beyond certain level of complexity. The
same is true for JavaScript, which, metaphorically speaking, became of
old age only after ten years of it's existence.

Cheers, have fun!
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-11 08:40
(Received via mailing list)
William James wrote:

> > require 'inline'
> >              for x in -39...39 do
> >      inline do |builder|
> >              double zi2 = 0.0;
> >                 zi = temp + temp + ci;
> >          }"
>
>   let cr = y - 0.5  and
>       if zi2 + zr2 > bailout then
>       let i = iterate
>         (float x / 40.0) (float y / 40.0) in
>       System.Console.Write( ( if 0 = i then "*" else " " ) )
>     done
>   done
>
>
> let start_time = Sys.time ()
> let _ = mandelbrot ();
> print_endline "";
> System.Console.Write (Sys.time () - start_time)

Using the built-in type complex makes the program shorter but
slower.

open Math.Complex;

let max_iterations = 1000

let iterate cmp =
  let rec loop z i =
    if i > max_iterations then
      0
    else
      if magnitude z >= 2.0 then
        i
      else
        loop (z * z + cmp) (i + 1)
  in
  loop zero 1

let mandelbrot () =
  for y = -39 to 38 do
    print_endline "";
    for x = -39 to 38 do
      let i = iterate
        (complex ((float y / 40.0) - 0.5) (float x / 40.0))  in
      System.Console.Write( ( if 0 = i then "*" else " " ) )
    done
  done


let start_time = Sys.time ()
let _ = mandelbrot ();
print_endline "";
System.Console.Write (Sys.time () - start_time)
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-11 09:07
(Received via mailing list)
Vetrivel Vetrivel wrote:

>
> BAILOUT = 16

I think that this should be 4.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-11 09:46
(Received via mailing list)
Igor Pirnovar wrote:
> OO itself is not chaotic and does not, as I have already said, promote
> anarchy, which you are suggesting.

Was I suggesting anarchy? I thought I was suggesting a specific feature:
Rip a method out of one class and apply it to another.

I fail to see how that's more inherently anarchistic than:

 - Re-opening classes at runtime
 - Redefining methods, or whole classes, also at runtime
 - Adding a method or mixing a module into just one instance
 - All of the above with user input (eval)
 - Doing no type checking whatsoever
 - Overriding basic operators (make 2+2==5)
 - Corrupt basic assumptions (make nil.nil? false) and crash

Ruby's strength is in what you're calling "anarchy" -- except when you
choose to call it "flexibility".

> There are rules that have to be
> adhered to, only they are much more relaxed than are rules in
> hierarchical structured pyramids of structured organizations.
[snip]
> There are rules that govern the freedom of selecting
> procedural or structured methods, and when to abide by the orthogonal OO
> principles. Failing to understanding these principles leads to chaos and
> anarchy.

You've certainly not done a good job of explaining or defining such
rules.

> The fact that you see meritocracy in the same light as
> aristocracy

Show me where I said that.

> In procedural languages you have to enforce these rules
> yourself, in OO ideally the language enforces these concepts.

Erm... Why aren't you using Java again?

If I wanted a language to enforce those rules, I'd be back to something
like:

class Hello {
  public static void main(String [] args) {
    System.out.println("Hello, world!");
  }
}

I don't. It's fine if the language can enforce them -- in Perl, I can do
things like 'use strict' or 'use warnings'. In Ruby, I can simply grep
through my source files to make sure I haven't stooped to using eval
anywhere I don't absolutely have to.

So, if there was an UnboundMethod#bind! method, which would bind that
method to an object completely unrelated, I could choose not to use that
method. So could you. I don't see how its very existence threatens that.

It's a lot easier to ignore functionality you don't need than it is to
find functionality you do need missing.

> Module is
> not a class,

Actually, Module _is_ a class.

> And
> lastly, an instance method should not be treated as a loosely defined
> function, nor should an object exhibit some foreign behaviour of some
> arbitrary function, it totally violates encapsulation.

So do:

 - instance_variable_set
 - instance_variable_get
 - send
 - instance_eval
 - Binding#eval
 - extend
 - class << foo

And, to a lesser extent:

 - Modules as mixins (unless _very_ carefully written, they're touching
the same instance variable namespace)
 - class_eval
 - include
 - const_set
 - define_method

Am I missing any?

If you wanted a language that enforced encapsulation, I say again, go
back to Java, or to C++. You'll find encapsulation in Ruby is every bit
as much convention as it is in Perl.

The language makes it harder to violate that convention by accident,
that's all. And if you want to enforce it, all you have to do is grep
through your codebase for cases of instance_variable_set, and similar
constructs.

Take a quick look at that first list. Have you really never used any of
those? Are you sure?

> Your propositions
> and suggestions translate into total chaos and anarchy, where any
> identity could be shared among all members of the universe

I'm suggesting that it be possible to rebind a method.

Again: How is that worse than any of the above? You're acting as if it
would destroy the fabric of the universe!

I was expecting opposition along the lines of "This would be difficult,
the way the Ruby interpreter is written." Instead, I'm getting the kind
of response I would expect from the bad old Rails community: "You can't
do that because we think it's a bad idea, so we're protecting you from
yourself."

> many objects are actors and actors are subjects with
> responsibilities and behaviours, by which you classify them.

Right. I don't know about you, but I classify them by their actual,
demonstrated behavior, not their ancestry.

Why, then, does the system for copying methods from one object to
another restrict by ancestry, and not by behavior?

>> Except Perl is not strictly procedural, and Javascript actually has a
>> very nice prototypal object system.
>>
>
> This is is pure baloney. Perl was designed as such,

And Linux was designed as a terminal emulator. Quite literally. Look
where it is now.

Now who's arguing aristocracy? Perl can never be OO, because it wasn't
designed that way? Languages evolve.

> The
> same is true for JavaScript, which, metaphorically speaking, became of
> old age only after ten years of it's existence.

That only shows how little you know about JavaScript. It was actually
originally written as a dialect of LISP, and only later given a C-like
syntax to make the PHBs happy.

Because of its Lisp heritage, I can guess, but cannot prove, that it
always had closures, and always had functions as first-class objects.
Attempting to look at the history of object-oriented Javascript, you
find that it is mostly about people finding ways to express the kind of
object systems they want, using the powerful prototypal object system
that was already in place.

In fact, when it comes down to it, there's no reason you can't program
Javascript the way you program Ruby. It's not difficult to write a sane
each() method, or add a class hierarchy (as opposed to prototypal
inheritance). However, it is much more difficult to write Ruby the way I
wrote Javascript, when I had to use it for more than just a web client,
and some things, as I've mentioned, are actually impossible. You speak
of "anarchy", but it worked, and it worked very well.
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 William James (Guest)
on 2009-02-11 10:00
(Received via mailing list)
Reid Thompson wrote:

> William James wrote:

> CFLAGS="-march=prescott -O2 -g -pipe" + feature splitdebug (
> everything compiled with debug except mandInC ).  -rwxr-xr-x  1
> rthompso staff         7104 2009-02-10 23:36 mandInC

To make timing more accurate, let's calculate the set 100 times
but draw it only 1 time.

Result:  1.99286559999999  (laptop with 2GHz Pentium M)


(**  Note that bailout has been changed.  **)
let bailout = 4.0
let max_iterations = 1000


let iterate ci cr =
  let rec loop zi zr i =
    if i > max_iterations then
      0
    else
      let temp = zr * zi  and
        zr2 = zr * zr  and
        zi2 = zi * zi  in
      if zi2 + zr2 > bailout then
        i
      else
        loop (temp + temp + ci) (zr2 - zi2 + cr) (i + 1)
  in
  loop 0.0 0.0 1

let mandelbrot n =
  for y = -39 to 38 do
    if 1 = n then  print_endline ""  else ();
    for x = -39 to 38 do
      let i = iterate
        (float x / 40.0) (float y / 40.0 - 0.5) in
      if 1 = n then
        System.Console.Write( ( if 0 = i then "*" else " " ) )
      else ();
    done
  done;;


let start_time = Sys.time () in
for iter = 1 to 100 do
  mandelbrot iter
done;
print_endline "";
System.Console.Write (Sys.time () - start_time);
print_endline "";
46a8ebdfabc2485407f89a2db5bdafb7?d=identicon&s=25 Igor Pirnovar (rooby)
on 2009-02-11 14:24
David Masover wrote:

> I fail to see how that's more inherently anarchistic than:
>
>  - Re-opening classes at runtime
>  - Redefining methods, or whole classes, also at runtime
>  - Adding a method or mixing a module into just one instance
>  - All of the above with user input (eval)
>  - Doing no type checking whatsoever
>  - Overriding basic operators (make 2+2==5)
>  - Corrupt basic assumptions (make nil.nil? false) and crash

Indeed, all this can lead to anarchy and chaos, but that is your doing!
There must be a reason for redefining a class, if it is a subversion
than indeed it is anarchy, but how many creators sabotage their own
creation?. Language enforcing the rules does not mean that it should
stop you from making incorrect assumptions such as 2+2==5.
Statistically, type checking is not needed and mostly presents an
unnecessary clutter in the code with little if any benefit at all. And
what's nil.nil - some devilish construct of yours?

> Ruby's strength is in what you're calling "anarchy" -- except when you
> choose to call it "flexibility".

I do not call Ruby anythingexcept OOPL from start to the end. And most
certainly all that you call inherently anarchistic above if used to
model the reality you are trying to reproduce with your design is power
unheard of in the traditional OOPLs.

> You've certainly not done a good job of explaining or defining such
> rules.

I did not invent nor made up those rules, they are spelt out in Booch,
and nicely packed in design patterns. You can adhere to these rules in
any language even assembler, it only is much harder to do so in
procedural languages. Besides, it is not so much about following these
rules as understanding them. Your misplaced comments about most of the
details you are bringing up in this discussion and most noticeably about
encapsulation show a serious deficit in this area on your part.

>> The fact that you see meritocracy in the same light as
>> aristocracy ...
> Show me where I said that.

Are not the following your words: "Except that Ruby enforces the
aristocracy with respect to which methods
belong to which classes". I have gone to great length explaining the
difference between taxonomy that classifies things by its membership and
the other that takes into account the merits. The two are orthogonal and
do not mix as you are suggesting by attributing knighthood based on
behaviour (activity, methods, functions, processing) rather on ancestral
principles based on name or membership, as is known to us throughout the
history.

> ... It's fine if the language can enforce them -- in Perl, I can do
> things like 'use strict' or 'use warnings'...
Again you are mixing apples and oranges. Perl's strict does not qualify
for encapsulation, orthogonality of aggregation or composition and
inheritance, for rule of favouring delegation over inheritance,... heck
I do not even know you understand what I am talking about! And I have no
time explaining or defining all this to you. For any OO programmer,
designer or analyst these are pure facts nobody questions or doubts any
more.

> So, if there was an UnboundMethod#bind! method, which would bind that
> method to an object completely unrelated, I could choose not to use that
> method. So could you. I don't see how its very existence threatens that.

You are a master of sabotage. I believe you do this only in forum
discussions and not to your code and creative processes, however if this
writing is a creative process, you must somewhat of an anarchist.

> It's a lot easier to ignore functionality you don't need than it is to
> find functionality you do need missing.

And what a generality is again this? I have not found it in any of the
pertinent methodologies discussed here. Most likely it is a convenient
concoction of yours for the sake of argument and no substance or merit
for that matter.

> Actually, Module _is_ a class.

Modularity packs abstractions into discrete units. Abstractions are
represented by classes. There is no way on the Earth to turn this
definition around.  Namely a class can never be a module nor is module a
class as you are suggesting. Yes, you could make your own concoctions
but that ain't gonna be OO!

> Am I missing any?

As I have shown you above, a great deal and much more.

Have fun, cheers
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2009-02-11 15:03
(Received via mailing list)
Just let him have his pain!

Blog: http://random8.zenunit.com/
Learn rails: http://sensei.zenunit.com/
91e1fb8bd265b7629491ab64c42f0906?d=identicon&s=25 Reid Thompson (Guest)
on 2009-02-11 16:00
(Received via mailing list)
On Wed, 2009-02-11 at 16:38 +0900, William James wrote:
> > >
> > >          for y in -39...39 do
> > >      end
> > >              double zr = 0.0;
> > >                 zi2 = zi * zi;
> > >                 }
> > > puts
> >
> >         zr2 = zr * zr  and
> >     print_endline "";
> > print_endline "";
> > System.Console.Write (Sys.time () - start_time)
>

as info -- pulled down and configured F# et al on my box.
compiled and ran the above code via Mono/F# -- gets in the .08xxx range
fairly consistently -- best run 0.075988
91e1fb8bd265b7629491ab64c42f0906?d=identicon&s=25 Reid Thompson (Guest)
on 2009-02-11 16:12
(Received via mailing list)
On Wed, 2009-02-11 at 23:59 +0900, Reid Thompson wrote:
> > > > #!/usr/local/bin/ruby
> > > >          puts "Rendering"
> > > >          end
> > > >              double zi = 0.0;
> > > >                 zr2 = zr * zr;
> > > >                     return 0;
> > > > Mandelbrot.new
> > >
> > >       let temp = zr * zi  and
> > >   for y = -39 to 38 do
> > > let _ = mandelbrot ();
> > > print_endline "";
> > > System.Console.Write (Sys.time () - start_time)
> >
>
> as info -- pulled down and configured F# et al on my box.
> compiled and ran the above code via Mono/F# -- gets in the .08xxx range
> fairly consistently -- best run 0.075988
>

not very familiar with mono/et al --- compiled with --optimize,
regularly gets in the .7xxx range, best 0.06399
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2009-02-11 16:19
(Received via mailing list)
Yeah it's macruby

Blog: http://random8.zenunit.com/
Learn rails: http://sensei.zenunit.com/
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-11 18:42
(Received via mailing list)
Igor Pirnovar wrote:
>>  - Overriding basic operators (make 2+2==5)
>>  - Corrupt basic assumptions (make nil.nil? false) and crash
>>
>
> Indeed, all this can lead to anarchy and chaos, but that is your doing!
>

Exactly my point. So if I am allowed these things which can lead to
anarchy, why am I not allowed this other thing that can lead to anarchy?

Unless you mean they are "my doing" in that I wrote these capabilities
into Ruby, which I didn't.

> Language enforcing the rules does not mean that it should
> stop you from making incorrect assumptions such as 2+2==5.
>

I'm talking about:

class Fixnum
  alias_method :old_plus, :+
  def +(other)
    if self == 2 && other == 2
      5
    else
      self.old_plus(other)
    end
  end
end

> Statistically, type checking is not needed and mostly presents an
> unnecessary clutter in the code with little if any benefit at all.

Ok, but what does that have to do with statistics? And does it not
strictly enforce the rules you seem to care about?

> And
> what's nil.nil - some devilish construct of yours?
>

All objects respond to .nil?, and I'm surprised you made it this far in
a discussion of Ruby without knowing about this.

And, since classes are open, you can do this:

class NilClass
  def nil?
    false
  end
end

Go ahead, type that into irb. Watch it crash on the very next command.

> power
> unheard of in the traditional OOPLs.
>

Traditional, like, I don't know, Smalltalk? It seems just as reflective.

> the other that takes into account the merits. The two are orthogonal and
> do not mix as you are suggesting by attributing knighthood based on
> behaviour (activity, methods, functions, processing) rather on ancestral
> principles based on name or membership, as is known to us throughout the
> history.
>

Except that which objects are allowed to have a certain method is
restricted entirely by ancestral principles.

I did not say that I saw a meritocracy in the same light as an
aristocracy -- that's something you're inferring beyond what I actually
said. In this particular instance, Ruby is _not_ a meritocracy.

>> ... It's fine if the language can enforce them -- in Perl, I can do
>> things like 'use strict' or 'use warnings'...
>>
> Again you are mixing apples and oranges. Perl's strict does not qualify
> for encapsulation, orthogonality of aggregation or composition and
> inheritance,

True enough. It is, however, an example of choice vs being forced to --
Perl's strict mode will force me to declare variables. However, if I
don't turn it on, the language will let me define variables as I like.

It is an unrelated feature, but Ruby does similar things -- in 1.9, we
have send and public_send. If I want to be safe, and respect
encapsulation, I use public_send. If I don't, I use send.

> And I have no
> time explaining or defining all this to you. For any OO programmer,
> designer or analyst these are pure facts nobody questions or doubts any
> more.
>

Clearly, I am an OO programmer. And clearly, I doubt them.

And clearly, you have time to write long, rambling responses that
_don't_ explain these principles. Argument from Authority?

>> So, if there was an UnboundMethod#bind! method, which would bind that
>> method to an object completely unrelated, I could choose not to use that
>> method. So could you. I don't see how its very existence threatens that.
>>
>
> You are a master of sabotage.
>

Nice ad-hominem. It doesn't answer my question.

>> It's a lot easier to ignore functionality you don't need than it is to
>> find functionality you do need missing.
>>
>
> And what a generality is again this? I have not found it in any of the
> pertinent methodologies discussed here.

No, I consider it to be a self-evident truth, and something you see in
the design of Ruby.

For example: The ability to deliberately break encapsulation, and use
instance_eval, or send instead of public_send, etc, is something I've
certainly found useful in my own code. Tell me, have you never found a
use for these? Or even for class_eval?

How would you feel if someone removed them, because they felt they were
"sabotage", that they violated the "purity" of Ruby's OO system?

Certainly, you don't want to just be using them all the time, because
that would lead to, as you said, "anarchy". But when you need them, you
need them, and nothing else will do.

>> Actually, Module _is_ a class.
>>
>
> Modularity packs abstractions into discrete units. Abstractions are
> represented by classes. There is no way on the Earth to turn this
> definition around.  Namely a class can never be a module nor is module a
> class as you are suggesting.
>

Modules are not classes, you are right. However, the global constant
Module is a class. That is what I meant.

Oh, and classes are modules. You can verify this for yourself:

Class.new.kind_of? Module
A246f7c0ce5f2909483d358bd9e83e4e?d=identicon&s=25 Mike Gold (mikegold)
on 2009-02-11 19:48
Igor Pirnovar wrote:
>
> I did not invent nor made up those rules, they are spelt out in Booch,
> and nicely packed in design patterns. You can adhere to these rules in
> any language even assembler, it only is much harder to do so in
> procedural languages. Besides, it is not so much about following these
> rules as understanding them. Your misplaced comments about most of the
> details you are bringing up in this discussion and most noticeably about
> encapsulation show a serious deficit in this area on your part.

This is the most telling part of the voluminous stream of consciousness
you've been piping to comp.lang.ruby lately.

If you are committed to measuring everything in accordance with Booch,
you will find a whole legion of sinners here.  Indeed, that I and others
keep wondering why you are not using Java or C++ makes sense in light of
this.  For the most part Ruby goes duck-typing route, which is
fundamentally different than the route of Java or C++
patterns/methodologies you find in Booch.

Ruby is like Lisp in this regard.  The flexibility is there to allow a
program to adapt to new information found only at runtime.  A program is
able to rewrite itself according to the situation.  This is the
essential power which made Lisp suitable for AI.  It is impossible in
Java or C++, unless you greenspun a half-ass lisp interpreter to do what
you need (http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule).

Take the example of delegation.  There is no notion of Java-like
interfaces or C++-like classes of just pure virtuals.  In Ruby a
delegate can have no relation, ancestry-wise, to the object it wraps.
It violates all the Booch rules: it should be outlawed!

Yet that's the Ruby way: create an object and "let it ride".  Just start
quacking and go.  To hell with the indoctrination ceremonies which
bestow permission to quack.  Strange women lying in ponds distributing
swords is no basis for a system of government!
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-11 19:59
(Received via mailing list)
On Wed, Feb 11, 2009 at 03:42:34AM +0900, David Masover wrote:
> Robert Klemme wrote:
> >
> >Just moving one method over is an ad
> >hoc solution which - when applied with only moderate frequency - will
> >give unreadable and thus unmaintainable code very soon.
>
> Again, I'm not seeing how this has any more potential for disaster than
> duck typing or metaprogramming. Those have as much capacity for misuse.

They also both have great capacity for brilliant use, which is really
the
point.  If I wanted a language that spent all its time holding my hand
and "protecting" me from myself, I'd use Python -- not Perl and Ruby.  I
have to wonder whether Robert's preferences for language design might
not
be better suited to Python.

Note that I'm not saying anything bad about Python, per se.  It's just
that my programming preferences are not well suited to its "one right
way
to do it" philosophy.


> called practical extraction and _report_ language, but they decided
> reports no longer belong in the core language. I know I'd be (slightly)
> happier with PHP if templating wasn't a part of the core language.

Really?  Without templating, I'm not sure there's a *point* to PHP.
It's
basically Perl with a lot of the good stuff stripped out, and templating
added into the core language.  In fact, with the growing ease of Ruby
use
for templating (via eruby, et cetera), PHP is rapidly becoming obsolete
in my world.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-11 20:03
(Received via mailing list)
On Wed, Feb 11, 2009 at 04:20:19AM +0900, Igor Pirnovar wrote:
> defended as a good OOPL, because it simply is not. It lacks so many
> distinct from pyramid and geriatric hierarchical structures which are
> the footprint for all the procedural languages. It takes to much effort
> in procedural languages to account for that which they lack!

I'm not sure you're clear on the definition of "orthogonal".

. . . and OOP is actually very hierarchical in a lot of ways, at least
as
practiced in most languages -- including, to a lesser extent, Ruby.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-11 20:15
(Received via mailing list)
On Wed, Feb 11, 2009 at 10:23:23PM +0900, Igor Pirnovar wrote:
> David Masover wrote:
> >
> > Ruby's strength is in what you're calling "anarchy" -- except when you
> > choose to call it "flexibility".
>
> I do not call Ruby anythingexcept OOPL from start to the end. And most
> certainly all that you call inherently anarchistic above if used to
> model the reality you are trying to reproduce with your design is power
> unheard of in the traditional OOPLs.

In that case, I think you're missing out on a lot of what Ruby has to
offer.  There's much more to it than object hierarchies.


> do not mix as you are suggesting by attributing knighthood based on
> behaviour (activity, methods, functions, processing) rather on ancestral
> principles based on name or membership, as is known to us throughout the
> history.

I think you must have completely misinterpreted what David said.  He
said
that Ruby enforces what you call an "aristocracy" model in some
respects,
not that aristocracy and meritocracy are the same in any way.


> >
> > ... It's fine if the language can enforce them -- in Perl, I can do
> > things like 'use strict' or 'use warnings'...
> Again you are mixing apples and oranges. Perl's strict does not qualify
> for encapsulation, orthogonality of aggregation or composition and
> inheritance, for rule of favouring delegation over inheritance,... heck
> I do not even know you understand what I am talking about! And I have no
> time explaining or defining all this to you. For any OO programmer,
> designer or analyst these are pure facts nobody questions or doubts any
> more.

Blessing provides encapsulation.  The extreme simplicity of generating
lexical closures can provide both encapsulation and protection stronger
than the average Ruby object provides.


> >
> > So, if there was an UnboundMethod#bind! method, which would bind that
> > method to an object completely unrelated, I could choose not to use that
> > method. So could you. I don't see how its very existence threatens that.
>
> You are a master of sabotage. I believe you do this only in forum
> discussions and not to your code and creative processes, however if this
> writing is a creative process, you must somewhat of an anarchist.

I have a couple of points to make:

  1. You're obviously trying to slander the speaker rather than address
  his points.  That's pretty offensive.

  2. If you want to keep using "anarchy" that way, you should probably
  try making a case for "anarchy" being an inherently bad thing first.


> >
> > Actually, Module _is_ a class.
>
> Modularity packs abstractions into discrete units. Abstractions are
> represented by classes. There is no way on the Earth to turn this
> definition around.  Namely a class can never be a module nor is module a
> class as you are suggesting. Yes, you could make your own concoctions
> but that ain't gonna be OO!

Let's see what ri says:

---------------------------------------------------------- Class: Module
     A +Module+ is a collection of methods and constants. The methods in
     a module may be instance methods or module methods. Instance
     methods appear as methods in a class when the module is included,
     module methods do not. Conversely, module methods may be called
     without creating an encapsulating object, while instance methods
     may not. (See +Module#module_function+)

     In the descriptions that follow, the parameter _syml_ refers to a
     symbol, which is either a quoted string or a +Symbol+ (such as
     +:name+).

        module Mod
          include Math
          CONST = 1
          def meth
            #  ...
          end
        end
        Mod.class              #=> Module
        Mod.constants          #=> ["E", "PI", "CONST"]
        Mod.instance_methods   #=> ["meth"]
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-11 20:17
(Received via mailing list)
On Wed, Feb 11, 2009 at 03:31:02AM +0900, Robert Dober wrote:
> That said I admit that one can write nice OO code in Perl with some discipline.
That's sorta the point of the way Perl does things: one can write good
code if one knows what one is doing.  One can write bad code in *any*
language if one does *not* know what one is doing.  I'd rather use a
language that allows me to write good code and bad code, as I choose,
than a language that disallows code better than "acceptable" and tries
(but fails) to disallow bad code.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-11 20:19
(Received via mailing list)
On Thu, Feb 12, 2009 at 12:17:26AM +0900, Julian Leviston wrote:
> Yeah it's macruby

Thanks.  I'll look into it.

Unfortunately, it seems rather Mac-specific, at first glance.  I was
hoping for something a bit more portable.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-11 20:55
(Received via mailing list)
Chad Perrin wrote:
> added into the core language.
Very true. However, templating as a part of the core language is perhaps
one of the stranger parts of it, and is certainly something which is
ripe for abuse.

I think the main point to PHP now is sheer ubiquity -- all the apps
already written in PHP, including some really impressive systems like
Drupal, and all the hosts which provide PHP out of the box, with the
programmer having to do nothing more complicated than FTP to deploy.
This also makes it dangerously quick to pick up -- you've already got a
cheap and/or free website that lets you FTP in some static HTML files,
and you want to, say, add a hit counter. Copy and paste some snippet
into that HTML, change the extension to .php, and you're now a PHP
developer.

Either way, that is sort of a representative sample -- templating is
part of the core language. It's really something that ought to be done
in a library -- there's more than one good templating system (haml,
anyone?), and you don't want your entire program to be a template.

Perl used to be the same way, though. I think a recent release --
"recent" meaning "within the past five years or so" -- they moved
"formats" out of the core language and into a library.

But I think that's getting even more offtopic, so to bring it back to
Ruby... The one piece that really seems out of place is the Regex
syntax, but I can't complain. Everything else, whether pure or not,
comes together in such a way as to make it easy to turn it into whatever
you need -- Markaby is another example of why not to build templating
into the core language. Why put something in the core language when it
can be done in a DSL?
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-11 20:58
(Received via mailing list)
Robert Dober wrote:
> can implement MI in?
>

I've been thinking about it for a bit, and no, I'm really not. Aside
from (maybe) performance, what's wrong with that implementation? After
all, Ruby has Module#ancestors, and the trick is older than dirt as the
various PATH variables in Unix.
2ee1a7960cc761a6e92efb5000c0f2c9?d=identicon&s=25 unknown (Guest)
on 2009-02-11 21:37
(Received via mailing list)
On Feb 11, 2:57 am, "William James" <w_a_x_...@yahoo.com> wrote:
> > RAM running gentoo with entire system compiled with
> let bailout = 4.0
>       if zi2 + zr2 > bailout then
>       let i = iterate
> done;
> print_endline "";
> System.Console.Write (Sys.time () - start_time);
> print_endline "";

This is over twice as fast as the OCaml version.
F# is impressive.
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2009-02-11 22:11
(Received via mailing list)
On 10.02.2009 19:42, David Masover wrote:
>
> It does, actually, assuming you called it with a hash of options. Perl
> objects are most commonly a blessed hash.

That's the first flaw of Perl's OO: you have the free choice to use
hashes or arrays (or even scalars?) as objects.

>>> a user from passing in a function to override one of mine, thus creating a
>   b: 12345,
> that both Foo and Bar are classes, each of which may have methods of
> their own -- in this case, Bar's methods (or properties) override Foo's.

Really?  I'd say they are overridden by Foo's because this comes later.
  But I'm not a JavaScript expert.

> To get something even close in Ruby, I'd have to do this:
>
> f = OpenStruct.new
> class << f
>   def c
>     #some method
>   end
> end

No.  This is a one off shot.  To get the equivalent of the JavaScript
version (if my JS does not fail me), you need to define a method which
does the initialization, e.g.

def Foo(o = Object.new)
   class <<o
     attr_accessor :bar, :baz

     def c
       printf "bar=%4d, baz=%4d\n", bar, baz
     end
   end

   o.bar = 123
   o.baz = 890

   o
end

Then you can do

x = Foo
y = Foo(Bar.new)
z = Foo(any_other_expression)

Although I have to say that I'd rather package this in a module and do

module Foo
   def self.create(o = Object.new)
     o.extend(self)
     o.bar = 123
     o.baz = 890
     o
   end

   attr_accessor :bar, :baz

   def c
     printf "bar=%4d, baz=%4d\n", bar, baz
   end
end

<snip/>

The details really do not matter.  My point is simply this: I prefer to
use Ruby over Perl because of the clean syntax as well as the profound
OO.  And I still have all (or at least most of) the options I have in
Perl's bare metal world.  I find the balance in Ruby highly superior.

>> Because in Ruby hackery (or call it "metaprogramming") is an add on,
>> i.e. you can use it in special situations, while in Perl you need to
>> do it to get basic things (OO) to work.
>
> There are, however, libraries to make the OO less painful in Perl.

Which still makes them non core artifacts and leave the option for
multiple OO models in the same program.  Doesn't sound healthy to me.

> Now, not doing that often is probably a good idea -- not using
> Kernel#eval often might also be a good idea. But I don't like it when a
> tool tells me what I may or may not do, simply because it's not a good idea.

Maybe you haven't come to appreciate the power gained from restriction.
  Often more creativity and productivity is unleashed in more restricted
environments.

> I'm not trying to sell Perl's OO as the best thing, or even "better".
> But I'm defending it as inherently less useful than Ruby's.

Is this really what you intended to say?

> Someone
> might as easily say that Ruby's OO is inherently less useful than
> Java's, because Java does stricter (static) type-checking.

As always it depends on the point of view - or the criteria you apply.
I do mostly OO programming - even in scripts - and for that I appreciate
the way OO is done much more than Perl's way.

Cheers

  robert
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-02-11 23:54
(Received via mailing list)
On 09/02/2009, David Masover <ninja@slaphack.com> wrote:

> variables -- so why should 'self' be exempted from the "quacks like" rule?
>

Actually you sort of can except the binding is not permanent.

module Kernel

  module Q175
    Require = Kernel.instance_method :require
    def scan
      ...
    end
  end

  undef_method :require
  def require file
    loc = Q175::scan file
    res = Q175::Require.bind(self).call file
    STDERR.puts "require: #{file} => #{loc}" if res && loc
    res
  end
end

Thanks

Michal
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-12 01:11
(Received via mailing list)
Robert Klemme wrote:
>>>>
>>> But this does not set properties, does it?
>>
>> It does, actually, assuming you called it with a hash of options.
>> Perl objects are most commonly a blessed hash.
>
> That's the first flaw of Perl's OO: you have the free choice to use
> hashes or arrays (or even scalars?) as objects.

Why is this a flaw? In Ruby, everything's an object. On closer
examination, we use instance variables in objects more or less the same
way a Perl object would use hash members.

>>
>> thus creating a spontaneous new child of both Foo and Bar. Keep in
>> mind that both Foo and Bar are classes, each of which may have
>> methods of their own -- in this case, Bar's methods (or properties)
>> override Foo's.
>
> Really?  I'd say they are overridden by Foo's because this comes
> later.  But I'm not a JavaScript expert.

Since Foo is a user-definable function, it's actually entirely up to the
author of said function. I believe the sample I gave was using the
argument to override defaults in Foo.

>> To get something even close in Ruby, I'd have to do this:
>>
>> f = OpenStruct.new
>> class << f
>>   def c
>>     #some method
>>   end
>> end
>
> No.  This is a one off shot.

You're right. I was simplifying.

>   end
>
>   o.bar = 123
>   o.baz = 890
>
>   o
> end

I suppose that is roughly equivalent. I would have chosen something
else, like:

module Foo
  def a
    ...
  end
  ...
end

def foo(o = Object.new)
  o.send :include, Foo
end

So, you can get close with something like:

foo(
  OpenStruct.new(
    :a => 'some_string',
    :b => 12345
  ).extend(Module.new {
    def c
      # some method
    end
  })
)

I don't know about you, but that reads a lot less naturally to me.
Fortunately, Ruby is flexible enough that if I really wanted it, I could
probably define some DSL that does the right thing -- something like:

foo(MyStruct.new {
  a 'some_string'
  b 12345
  c do
    # some method
  end
})

> The details really do not matter.  My point is simply this: I prefer
> to use Ruby over Perl because of the clean syntax as well as the
> profound OO.  And I still have all (or at least most of) the options I
> have in Perl's bare metal world.  I find the balance in Ruby highly
> superior.

I agree. Or rather, not so much because the OO is profound, but because
it is much cleaner to access, for most things.

>>> Because in Ruby hackery (or call it "metaprogramming") is an add on,
>>> i.e. you can use it in special situations, while in Perl you need to
>>> do it to get basic things (OO) to work.
>>
>> There are, however, libraries to make the OO less painful in Perl.
>
> Which still makes them non core artifacts and leave the option for
> multiple OO models in the same program.

I don't see that being more of a problem than duck typing vs other
models in Ruby.

If you want to be consistent within a program, write up a coding style
for that program. If you want your language to enforce a coding style,
Java and Python will each do that for you, in their own ways.

>> Now, not doing that often is probably a good idea -- not using
>> Kernel#eval often might also be a good idea. But I don't like it when
>> a tool tells me what I may or may not do, simply because it's not a
>> good idea.
>
> Maybe you haven't come to appreciate the power gained from
> restriction.  Often more creativity and productivity is unleashed in
> more restricted environments.

Like Picasso's Blue Period, I get it. And it can certainly be useful for
learning.

I still don't see why it's good for the _environment_ to do that
restriction, rather than making it self-imposed. Certainly, I almost
never allow myself to use eval, and my code is better for it -- but note
that key word. _Almost_ never.

>> I'm not trying to sell Perl's OO as the best thing, or even "better".
>> But I'm defending it as inherently less useful than Ruby's.
>
> Is this really what you intended to say?

Probably not. Probably "defending it as _not_ inherently less useful..."

>> Someone might as easily say that Ruby's OO is inherently less useful
>> than Java's, because Java does stricter (static) type-checking.
>
> As always it depends on the point of view - or the criteria you apply.
> I do mostly OO programming - even in scripts - and for that I
> appreciate the way OO is done much more than Perl's way.

I do mostly OO programming, and I prefer Ruby -- but as a matter of
taste. I've just had enough experience with Perl to respect it, too,
even its object system.

I've also had enough experience with PHP to lose all respect for it...
The problem with PHP is they have absolutely no taste. (Apologies to
Steve Jobs.)
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-12 01:22
(Received via mailing list)
Michal Suchanek wrote:
>> theme? After all, what ties the method to the object -- isn't it mostly
>> going to be calling instance methods, and occasionally accessing instance
>> variables -- so why should 'self' be exempted from the "quacks like" rule?
>>
>>
>
> Actually you sort of can except the binding is not permanent.
>

No, I don't think so. I've tried in a method somewhat similar to yours,
and I get the same results.

> module Kernel
>

That's probably why. Everything includes Kernel, so if you grab an
UnboundMethod from Kernel, you should be able to apply it everywhere.

Try this:

module Foo
  def foo
    :foo   #ok, I'm unimaginative
  end
end

Foo.instance_method(:foo).bind(Object.new).call

See what happens? Doesn't matter whether Foo is a class or a module, you
can only bind methods of it to objects which are somehow its
descendants. If it's a module, you can only do this to things which have
included that module, making it somewhat less useful.

Speaking of which, modifying Kernel -- yet another thing more dangerous
than letting UnboundMethods bind to anything.
91e1fb8bd265b7629491ab64c42f0906?d=identicon&s=25 Reid Thompson (Guest)
on 2009-02-12 14:07
(Received via mailing list)
William James wrote:
>> seconds.  This is an Intel(R) Core(TM)2 CPU 6320  @ 1.86GHz box w 2GB
>> RAM running gentoo with entire system compiled with
>> CFLAGS="-march=prescott -O2 -g -pipe" + feature splitdebug (
>> everything compiled with debug except mandInC ).  -rwxr-xr-x  1
>> rthompso staff         7104 2009-02-10 23:36 mandInC
>
> To make timing more accurate, let's calculate the set 100 times
> but draw it only 1 time.
>
> Result:  1.99286559999999  (laptop with 2GHz Pentium M)



Echo delay is 2s and 23737us

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

/**
 * this function is for computing the time difference between timeval x
and y
 * the result is stored in result
 */
int
timeval_subtract (struct timeval *result, struct timeval *x, struct
timeval *y)
{
    /* Perform the carry for the later subtraction by updating y. */
    if (x->tv_usec < y->tv_usec) {
        int nsec = (y->tv_usec - x->tv_usec) / 1000000 + 1;
        y->tv_usec -= 1000000 * nsec;
        y->tv_sec += nsec;
    }
    if (x->tv_usec - y->tv_usec > 1000000) {
        int nsec = (x->tv_usec - y->tv_usec) / 1000000;
        y->tv_usec += 1000000 * nsec;
        y->tv_sec -= nsec;
    }

    /* Compute the time remaining to wait.
    tv_usec is certainly positive. */
    result->tv_sec = x->tv_sec - y->tv_sec;
    result->tv_usec = x->tv_usec - y->tv_usec;

    /* Return 1 if result is negative. */
    return x->tv_sec < y->tv_sec;
}

int iterate (double x, double y)
{
    int BAILOUT = 16;
    int MAX_ITERATIONS = 1000;
    double cr = y-0.5;
    double ci = x;
    double zi = 0.0;
    double zr = 0.0;
    double zr2 = 0.0;
    double zi2 = 0.0;
    int i = 0;
    double temp = 0.0;

    while (1)
    {
        i += 1;
        temp = zr * zi;
        zr2 = zr * zr;
        zi2 = zi * zi;
        zr = zr2 - zi2 + cr;
        zi = temp + temp + ci;

        if ( zi2 + zr2 > BAILOUT)
        {
            return i;
        }
        if ( i > MAX_ITERATIONS)
        {
            return 0;
        }
    }
}

int main()
{
    int y = -39;
    int x = -39;
    int i = -1;
    int loop = 1;
    struct timeval start, stop, echodelay;  // start, stop and echo
delay times

    if((gettimeofday(&start, NULL)) == -1)
    {
        perror("gettimeofday");
        exit(1);
    }

    for (loop == 1; loop <= 100; ++loop)
    {
        for (y = -39; y <= 39; ++y)
        {

            if (loop == 1){printf("\n");}
            for (x = -39; x <= 39; ++x)
            {
                i = iterate(x/40.0, y/40.0);
                if (loop == 1)
                {
                    if (i == 0)
                        printf("*");
                    else
                        printf(" ");
                }
            }
        }
    }

    if((gettimeofday(&stop, NULL)) == -1)
    {
        perror("gettimeofday");
        exit(1);
    }
    /* compute time delay */
    timeval_subtract(&echodelay, &stop, &start);

    printf("\nEcho delay is %ds and %dus\n", echodelay.tv_sec,
echodelay.tv_usec);

    return 0;

}
91e1fb8bd265b7629491ab64c42f0906?d=identicon&s=25 Reid Thompson (Guest)
on 2009-02-12 14:19
(Received via mailing list)
William James wrote:
>> seconds.  This is an Intel(R) Core(TM)2 CPU 6320  @ 1.86GHz box w 2GB
>> RAM running gentoo with entire system compiled with
>> CFLAGS="-march=prescott -O2 -g -pipe" + feature splitdebug (
>> everything compiled with debug except mandInC ).  -rwxr-xr-x  1
>> rthompso staff         7104 2009-02-10 23:36 mandInC
>
> To make timing more accurate, let's calculate the set 100 times
> but draw it only 1 time.
>
> Result:  1.99286559999999  (laptop with 2GHz Pentium M)

mono + F# = 3.919404  ( hits 3.9x... range consistently)
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-12 20:25
(Received via mailing list)
On Thu, Feb 12, 2009 at 03:47:39AM +0900, Mike Gold wrote:
>
> Yet that's the Ruby way: create an object and "let it ride".  Just start
> quacking and go.  To hell with the indoctrination ceremonies which
> bestow permission to quack.  Strange women lying in ponds distributing
> swords is no basis for a system of government!

That is a beautiful segue into cultural reference, an apt summation of
your message as a whole in a concluding statement, and the tail end of
what was a well presented address of Igor's entire attitude in this
thread.  Well done.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-12 20:33
(Received via mailing list)
On Thu, Feb 12, 2009 at 04:52:50AM +0900, David Masover wrote:
>
> But I think that's getting even more offtopic, so to bring it back to
> Ruby... The one piece that really seems out of place is the Regex
> syntax, but I can't complain. Everything else, whether pure or not,
> comes together in such a way as to make it easy to turn it into whatever
> you need -- Markaby is another example of why not to build templating
> into the core language. Why put something in the core language when it
> can be done in a DSL?

My attitude is that PHP *is* a DSL.  It actually started out as a DSL
written in Perl, in fact -- then spun off into its own monstrosity,
notable in positive respects just for its eventual ubiquity and the fact
it ran faster on its own than it did as a Perl library.  I guess that's
just one man's opinion, though.
46a8ebdfabc2485407f89a2db5bdafb7?d=identicon&s=25 Igor Pirnovar (rooby)
on 2009-02-12 22:24
(1)
--------------------
David Masover wrote:
> All objects respond to .nil?, and I'm surprised you made it this far in
> a discussion of Ruby without knowing about this.
>
> And, since classes are open, you can do this:
>
> class NilClass
>   def nil?
>     false
>   end
> end
>
> Go ahead, type that into irb. Watch it crash on the very next command.

I have told you are the master of sabotage. Now tell me why on Earth
would one define things like { true==false } and { 2+2==5 }. I have more
trouble with Ruby crashing because of your sabotage! But that I can live
with, since I understand that Ruby internals depend on the premise {
true != false }!

As for your surprise that how far I have come, I must tell you that I am
only surprised I keep debating you. This is what happens when one
engages in public debates :( Much of what you are saying may be true
from your perspective, however, I simply do not have time to babble so
much.


(2)
----------------
Mike Gold wrote:
> If you are committed to measuring everything in accordance with Booch,
> you will find a whole legion of sinners here.  Indeed, that I and others
> keep wondering why you are not using Java or C++ makes sense in light of
> this.  For the most part Ruby goes duck-typing route, which is
> fundamentally different than the route of Java or C++
> patterns/methodologies you find in Booch.

Perhaps you are mislead by the nature of the discussion here, which has
deformed into something other than what the thread's title suggests. I
am not an OO purist and should basically be rather surprised at most of
what you've said above, mostly because of how I entered this discussion.
Let me repeat:

>> Ruby and Perl are two totally different programing
>> environments and are really not to be compared with regards
>> to their run time performance. With Ruby the performance
>> issue is shifted to the entire project life cycle, and indeed
>> to the complexity of the project. Mere execution time of an
>> application represents only a tiny fraction of what is truly
>> measured when comparing procedural language like Perl and
>> object oriented Ruby. If you compare the two languages in
>> this respect Perl doesn't come even close to where Ruby stands.
>> In fact I believe if you look at performance issues from this
>> angle, Ruby stands out very proudly as the best performing
>> programming language of all times.

Most likely, with my focus on OO, I am also responsible for the
splintering of this discussion into many branches. But the fact remains
that despite some of its immaturities Ruby is one of the best OOPLs
around today.

I have also repeatedly praised Ruby's inherent duck-typing philosophy,
which ironically seems to be one of the strongest points my opponents
make, when they mindlessly and unjustly build it up as significant
Ruby's flaw. The other point that I was arguing was that Ruby's
flexibility is not its fault but its strength, which again the opponents
of the idea that Ruby is setting standards for future OOP language
developments are constantly attacking with irrelevant arguments. They
support their attacks by dissecting nonsensical algorithms that in
normal circumstances indeed are inherently bad or even evil. Ruby with
many of its extensions, some of which indeed are  shared with more
procedural Perl and OB (object-based) Lisp, but especially, as you say,
with its ability to allow programs to effectively rewrite and redefine
themselves at runtime, is a powerful tool. All these attributes do not
make Ruby a procedural language, it remains one of the best, if not The
best, OOPLs around today!

> Take the example of delegation.  There is no notion of Java-like
> interfaces or C++-like classes of just pure virtuals.  In Ruby a
> delegate can have no relation, ancestry-wise, to the object it wraps.
> It violates all the Booch rules: it should be outlawed!

I could not disagree more. You are suggesting the rigidity that can only
be attributed to literary interpretation of the "scripture". It is in
fact Ruby's virtue that it did away with unnecessary virtuals and
abstract classes. But as I am repeatedly saying, it is up to the
designer to ignore these features or reinforce them. Go ahead and
reinforce them with an "abstract" class of "virtual" methods that do
nothing but throw exceptions, to make sure you actually define them. At
the end My code will be shorter and more elegant, and true, for a Java
or C++ virtuoso perhaps less legible.

(3)
------------------
Chad Perrin wrote:
> I'm not sure you're clear on the definition of "orthogonal".
> . . . and OOP is actually very hierarchical in a lot of ways,
> at least as practiced in most languages -- including, to a
> lesser extent, Ruby.

The term "orthogonal" is not an OOM (OO methodology) term, though it is
often used in texts and discussions pertaining to OO. Its meaning in OOM
discussions is an evolved meaning that expands even the definition in
Oxford dictionary, where it is explained merely as something
"right-angled". Logically in OOM the term loosely means "the opposite".
An object organization is flat organization, and is orthogonal to
structured pyramid organization. "Is-a" relationship defines hierarchy
and is orthogonal to "has-a" relationship which represents aggregation
or composition. In flat organization one set of rules apply, while in
the structured organization orthogonal rules apply. In this respect
procedural programing is orthogonal to OOP. Now the tricky part is that
OO includes procedural programming as a "part-of" or a "has-a" thing.
This means that programming in procedural way in an OOPL should be
possible without any effort, however, the reverse is not true because
the two programming paradigms are orthogonal. Again this does not mean
that in procedural language it is not possible to program in OO
programing paradigm, it only takes extraordinary effort and/or overhead
to do so. This is how orthogonality is accounted for with respect to OOP
and procedural programming.

Perl is an excellent example of what was just said. It takes an
extraordinary effort to use it as an OOPL. It requires that the
programmer knows much more about OO rules than the programmer who uses
Ruby where everything is an object. A totally and utterly different
question is whether you use these languages correctly be it Perl, C,
C++, Java, Ruby or ooCobol. This is where most of us fail most of the
time, and that is why Design Patterns and Booch OOA/D exist.
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-12 23:28
(Received via mailing list)
Igor Pirnovar wrote:
>>   def nil?
>>     false
>>   end
>> end
>>
>> Go ahead, type that into irb. Watch it crash on the very next command.
>>
>
> I have told you are the master of sabotage.

Why am I still feeding this troll?

> Now tell me why on Earth
> would one define things like { true==false } and { 2+2==5 }.

For fun.

But no, you wouldn't on a real project. Because despite what you seem to
think, the fact that a language feature is there doesn't in any way
imply that you have to use it.

> I have more
> trouble with Ruby crashing because of your sabotage!

Oh, you mean you've actually defined things like (nil.nil? == false)?
That's not very smart.

> Much of what you are saying may be true
> from your perspective, however, I simply do not have time to babble so
> much.
>

And yet, obviously, you do, or we wouldn't have received this message.
Something to think about before you reply.

The only thing you don't seem to have time for is forming a logical
argument.

> I have also repeatedly praised Ruby's inherent duck-typing philosophy,
> which ironically seems to be one of the strongest points my opponents
> make, when they mindlessly and unjustly build it up as significant
> Ruby's flaw.

I don't think anyone's suggesting it's a flaw -- only that your
philosophy would seem to make it one.

For example, if duck typing is not a flaw, why should I not be able to
borrow methods from unrelated classes? If the method works, clearly the
two classes are of the same duck type.

> The other point that I was arguing was that Ruby's
> flexibility is not its fault but its strength,

Ah. So when it's flexibility you like, it's a strength. When it's
flexibility you don't like, it's "anarchy". Got it.

> All these attributes do not
> make Ruby a procedural language,
>

Ruby can, in fact, be used as an exceptionally good procedural language.

>> Take the example of delegation.  There is no notion of Java-like
>> interfaces or C++-like classes of just pure virtuals.  In Ruby a
>> delegate can have no relation, ancestry-wise, to the object it wraps.
>> It violates all the Booch rules: it should be outlawed!
>>
>
> I could not disagree more. You are suggesting the rigidity that can only
> be attributed to literary interpretation of the "scripture". It is in
> fact Ruby's virtue that it did away with unnecessary virtuals and
> abstract classes.

Looks like you also don't understand sarcasm.

> ------------------
> Chad Perrin wrote:
>
>> I'm not sure you're clear on the definition of "orthogonal".
>>
>
> Logically in OOM the term loosely means "the opposite".

I have never heard it used to mean that, in computer science or
otherwise.

It means, roughly, neither dependent nor mutually exclusive -- if two
things are orthogonal, they have no side effects on each other.

For example, object oriented programming is orthogonal to regular
expressions. You can have a language with rich regex support and no OO,
or, conversely, a language with rich OO and no builtin regex support. Or
you can have a language with both -- in which case, you can probably
make large changes to the object system without affecting regexes, and
vice versa.

Within an object system, I might call two modules "orthogonal" if I can
include one, the other, neither, or both into my class without any
problems -- and, specifically, if I can include both without one
affecting the other. I believe Comparable and Enumerable are orthogonal
in that way.

Further reading:

http://en.wikipedia.org/wiki/Orthogonality#Computer_science

I think you'll probably find that you are the only person on this forum
using "orthogonal" to mean "opposite", because it does not. In fact, you
will not find "opposite" on that page -- despite wildly different
definitions in each of the _eight_ fields mentioned.

I wonder why you didn't simply say "opposite", if that's what you meant?
Or were you just trying to sound smart by using big words?
4828d528e2e46f7c8160c336eb332836?d=identicon&s=25 Robert Heiler (shevegen)
on 2009-02-13 14:21
> Looks like you also don't understand sarcasm.

Well David, sarcasm does not bode extremely well with written text.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-13 20:53
(Received via mailing list)
On Fri, Feb 13, 2009 at 06:22:45AM +0900, Igor Pirnovar wrote:
>
> Perhaps you are mislead by the nature of the discussion here, which has
> deformed into something other than what the thread's title suggests. I
> am not an OO purist and should basically be rather surprised at most of
> what you've said above, mostly because of how I entered this discussion.

Actually, he was probably misled by the fact that you keep using the
"fact" that Perl is a "procedural language" as a means of attacking it,
and holding up Ruby's OO-ness as proof of its superiority, then follow
that up by holding up Booch as the standard of all that is good and
right
in the world of programming technique.


> many of its extensions, some of which indeed are  shared with more
> procedural Perl and OB (object-based) Lisp, but especially, as you say,
> with its ability to allow programs to effectively rewrite and redefine
> themselves at runtime, is a powerful tool. All these attributes do not
> make Ruby a procedural language, it remains one of the best, if not The
> best, OOPLs around today!

I don't think anyone's talking about Ruby's duck typing as a flaw of the
language.  One or two may have used its duck typing as being similar to
some of the more dynamic aspects of Perl (and JavaScript), however, in
pointing out that dynamism isn't always bad.  You seem to completely,
and
repeatedly, miss that point in your attacks on Perl, though -- when you
keep using its more dynamic aspects as "evidence" of how much it sucks.
The point people are trying to make when they bring up Ruby
characteristics like duck typing is not some claim that duck typing
sucks, as you assert here, but that duck typing is *good*, thus proving
that your distaste for Perl's similarly dynamic characteristics is just
that: *your* distaste.  It's not a universally accepted sign of badness,
as you seem to want everyone to believe.

In fact, it may have been implied that, in attacking Perl for its
dynamic
characteristics while blindly praising Ruby's in almost the same breath,
you are behaving hypocritically.  From where I'm sitting, that's exactly
what you seem to be doing; praising Ruby for things that are, in
principle, exactly the same as the things for which you deplore Perl.


> designer to ignore these features or reinforce them. Go ahead and
> reinforce them with an "abstract" class of "virtual" methods that do
> nothing but throw exceptions, to make sure you actually define them. At
> the end My code will be shorter and more elegant, and true, for a Java
> or C++ virtuoso perhaps less legible.

You're the one trying to use the "scripture" as the final Word on all
that is good and right in the world of programming.  The above quote was
just someone applying your own "logic" to Ruby, and showing you that
your
ham-fisted attempt to wield Booch as a bludgeon in this discussion
doesn't achieve what you seem to think it does -- elevating Ruby to the
status of "awesome" while bringing Perl down to the status of "suck".


> often used in texts and discussions pertaining to OO. Its meaning in OOM
> This means that programming in procedural way in an OOPL should be
> possible without any effort, however, the reverse is not true because
> the two programming paradigms are orthogonal. Again this does not mean
> that in procedural language it is not possible to program in OO
> programing paradigm, it only takes extraordinary effort and/or overhead
> to do so. This is how orthogonality is accounted for with respect to OOP
> and procedural programming.

I know it's not an OO term.  Where did you get the crazy idea I
suggested
it was?

The term "orthogonal" *never* means "opposite", *ever* -- except in
cases
where it is misused, as you used it, just as "infer" never means "imply"
except when misused, and "car" never means "golf club" except when
misused, and "Empire State Building" never means "Eggs Benedict" except
when misused.

The use of the term "orthogonal" in discussions such as this should only
be used metaphorically, and metaphorically "opposite" would be something
that goes back whence the compared object came, not in a completely
different direction the way "orthogonal" does.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-13 20:58
(Received via mailing list)
On Fri, Feb 13, 2009 at 07:26:11AM +0900, David Masover wrote:
>
> Why am I still feeding this troll?

I think it's because, like me, you may still not be 100% certain whether
he's a troll or just thick-headedly incapable of grasping your argument.


>
> The only thing you don't seem to have time for is forming a logical
> argument.

. . . or understanding one (yours).


>
> Ah. So when it's flexibility you like, it's a strength. When it's
> flexibility you don't like, it's "anarchy". Got it.

I just quoted this because it bears repeating, in case he didn't notice
it sufficiently well the first time.


> make large changes to the object system without affecting regexes, and
> http://en.wikipedia.org/wiki/Orthogonality#Computer_science
>
> I think you'll probably find that you are the only person on this forum
> using "orthogonal" to mean "opposite", because it does not. In fact, you
> will not find "opposite" on that page -- despite wildly different
> definitions in each of the _eight_ fields mentioned.

Excellent explanation.  Thank you for expanding upon my point so
clearly.
Fd22ee3cfc7dac283ce8e451af324f7d?d=identicon&s=25 Chad Perrin (Guest)
on 2009-02-13 21:00
(Received via mailing list)
On Fri, Feb 13, 2009 at 10:19:38PM +0900, Marc Heiler wrote:
> > Looks like you also don't understand sarcasm.
>
> Well David, sarcasm does not bode extremely well with written text.

The sarcasm in question struck me as *incredibly* obvious and well
placed.  Honestly -- do you think it could be reasonably believed that
anyone was seriously recommending that anything not endorsed by Booch
should be ripped out of the Ruby language?
46a8ebdfabc2485407f89a2db5bdafb7?d=identicon&s=25 Igor Pirnovar (rooby)
on 2009-02-15 21:15
Chad Perrin wrote:
David Masover wrote:
> Oh, you mean you've actually defined things like
> (nil.nil? == false)? That's not very smart.

Indeed, any logical premise is possibe until proven wrong. There are
domains in which true == false, or 2+2=5 for that matter. They are yust
not the domains you usualy work in. Your writing shows limited
flexibility and rigidity that are the thing of the past.

>> Logically in OOM the term loosely means "the opposite".

> I have never heard it used to mean that, in computer science or
otherwise.

Of course not - this is not hard to guess from your anything but
enlightening arguments. The keyword in my definition of the term
orthogonal is "loosely", which you missed despite including it in the
quote. For OO and procedural programming the orthogonality comes to mind
due to the fact that the first deals with vertical pyramid - structured
organizations, while the other with flat object organizations.  It is
not so much that these two are opposite, but they definitely are
perpendicular to each other. The fact that each of these two
organizations in their respective domains employ orthogonal operations
makes them loosely opposite. Of course if you have trouble seeing what's
orthogonal, you are at a loss here. If you would ever open Grady Booch's
OOA/D or Ivar Jacobson's OO Software Engineering you would see countless
occurrences of this term. In fact one of the first things you ever learn
in Booch is about the orthogonality of the class and object structure,
whereby each complex system can be viewed as both a class structure and
as an orthogonal to it object structure.  Class exhibits a "is-a"
relationship property while object structure its orthogonal or opposite
"has-a" relationship. On the other hand Jacobson's analysis model is
based on there dimensional space defined by three mutually orthogonal
entities: behaviour, presentation, and information (data) ... Needless
to say that the two OOM models were accepted by every other computer
scientist and they subsequently use the term in question throughout
their work. You really do not have to advertise your ignorance ;)



Chad Perrin wrote:
> Actually, he was probably misled by the fact that you keep
> using the "fact" that Perl is a "procedural language" as a
> means of attacking it, and holding up Ruby's OO-ness as
> proof of its superiority, then follow that up by holding
> up Booch as the standard of all that is good and right
> in the world of programming technique.

Indeed, Perl is a procedural language, and the OO is only its extension.
You either did not read my posts or perhaps you want to ignore all the
arguments that explain how OO is a bonus in Perl, and that it is far too
much trouble to use. The true Perl power is in it's procedural features,
and its OO extension spells trouble for every project that reaches the
entry level complexity if managed by Ruby. It may appear that I have
been too negative about Perl, but that is not really how I feel about
it, namely, I love Perl but not for its OO features but for what it
really is - and that undoubtedly is one of the pearls between the
procedural languages. Hey, C can also be used as a language in OO
environment thanks to its GNOME extension, and I can argue that C/GNOME
combination is much more powerful than Perl's OO extension!
1bc63d01bd3fcccc36fb030a62039352?d=identicon&s=25 David Masover (Guest)
on 2009-02-16 10:50
(Received via mailing list)
Igor Pirnovar wrote:
> Chad Perrin wrote:
> David Masover wrote:
>
>> Oh, you mean you've actually defined things like
>> (nil.nil? == false)? That's not very smart.
>>
>
> Indeed, any logical premise is possibe until proven wrong. There are
> domains in which true == false, or 2+2=5 for that matter. They are yust
> not the domains you usualy work in.

I'd be curious to know in what Ruby application a true==false or 2+2=5
is actually a good idea.

> For OO and procedural programming the orthogonality comes to mind
> due to the fact that the first deals with vertical pyramid - structured
> organizations, while the other with flat object organizations.  It is
> not so much that these two are opposite, but they definitely are
> perpendicular to each other.

In fact, they are orthogonal -- in the computer science definition of
the term. That is, you can easily have both in a language. Both Perl and
Ruby are proof of this -- you can write Ruby code which is barely even
aware of the fact that it is dealing with objects, and you can write
Perl code that doesn't so much as touch a bare string without going
through an object.

For that matter, we have even more blatant examples: C++ is an
object-oriented language, and people are often encouraged to use objects
almost exclusively, instead of primitives. It is also almost a perfect
superset of C, a procedural language. Do you consider C++ to be "only"
an extension, and not "true" OO?

> The fact that each of these two
> organizations in their respective domains employ orthogonal operations
> makes them loosely opposite.

Perhaps. But they are not mutually exclusive, as I have shown. And I
didn't need an argument from authority to do it.

> If you would ever open Grady Booch's
> OOA/D or Ivar Jacobson's OO Software Engineering you would see countless
> occurrences of this term.

Probably using it properly, I would guess.

> You really do not have to advertise your ignorance ;)
>

Let me ask something -- does anyone else reading this thread think I am
wrong?

I'm certainly ignorant with respect to those particular authors. I also
don't find them very relevant -- my peers seem to be agreeing with me,
despite your veiled (and blatant) character attacks, in lieu of actually
putting up an argument.

Does that mean that all of us are wrong, and you are right?

If so, you're unlikely to convince us of our "ignorance" by continuing
to cite various authors who may or may not actually agree with you.
You're going to have to actually think about what you're saying.


> Indeed, Perl is a procedural language, and the OO is only its extension.
> You either did not read my posts or perhaps you want to ignore all the
> arguments that explain how OO is a bonus in Perl, and that it is far too
> much trouble to use.

How is "too much trouble" in any way an objective argument?

You know, from now on, I've decided I'm not going to write unit tests.
They are too much trouble. (Sarcasm, if you didn't get that.)

> The true Perl power is in it's procedural features,
>

Wrong. "The true Perl" power rests in two things:

There is more than one way to do it.
Easy things are easy, and hard things are possible.

Ruby borrows from all over the place, including Perl -- the regex syntax
is pretty obviously lifted straight from Perl, to where it's almost
surprising that it doesn't use libpcre. For that matter, so is the
ability to use or imply parentheses, and the general philosophy of "Do
What I Mean", especially with regards to syntax.

> and its OO extension spells trouble for every project

Have you looked at CPAN lately? It seems just about every project at
least provides an OO interface. They are quite useful, and there are a
few libraries which are OO, convenient to use, and much farther along
than anything Ruby has to offer. POE::Component::IRC is an example --
completely object-oriented, both internally and in usage, and yet better
than anything I have found so far in Ruby.

In fact, I'll suggest that the very existence of POE is a
counterexample. That "OO extension" doesn't seem to have spelled trouble
here. It seems to have spelled success.

> Hey, C can also be used as a language in OO
> environment thanks to its GNOME extension, and I can argue that C/GNOME
> combination is much more powerful than Perl's OO extension!
>

Having not used that, I can't comment, but let's take a step back.

Ruby is written in C. In fact, Ruby provides a C API.

So what's the difference between programming Ruby in C, using the C API,
versus writing it in Ruby?

Syntax, mostly.

I think you would find that with the right preprocessor, Perl is no less
object-oriented than Java, which is only slightly less so than Ruby
(Java has primitive types). And as a nice side effect, Perl might even
let you write such a preprocessor as a module -- just look at the
ACME::Lingua::Pirate::Perl for an example.

And I think that with enough metaprogramming, there really isn't very
much Ruby prevents you from doing that you could do with Perl. About the
only thing I can think of is that rebinding example I ran into, and Perl
does multi-inheritance instead of mixins.

No, if you were looking for a fundamental difference, of the kind that
might be worth debating, are between languages like these and languages
like Erlang, Haskell, Scheme, and so on -- languages of a completely
different paradigm -- instead of realizing TIMTOWTDI.

After all, why should you care? If I got UnboundMethod#rebind!, I
strongly doubt it would force you to rewrite a single line of code
you've written, or even to realize it had happened. It wouldn't shake
the foundations of your ivory tower of the Holy Order of Object
Orientedness any more than the fact that Ruby is written in C would, or
the fact that Kernel#autoload uses the native C's require instead of
whatever Ruby Kernel#require you overload, or the fact that Rubyists
sometimes do stupid things like using string comparisons to test
versions.

The stronger argument might be that it's hard to do, and that it would
change the _internal_ representation of Ruby objects and classes too
much -- as opposed to changing the philosophical, platonic _ideals_ of
Ruby objects. It might also be _conceptually_ difficult to do -- there
might be many things I haven't thought of, that become undefined, in the
same way that it's hard to prevent an object from being modified while
it's being iterated over.

But is that true? I haven't heard it from you or anyone else, and I
don't know. But those are the worthwhile arguments to have -- is it
actually difficult to do this, and will it actually cause problems? Or
are we just trying to protect programmers from themselves, instead of
treating them like adults?
This topic is locked and can not be replied to.