Ruby vs Perl performance

[Marc Heiler]

Looks like you also don't understand sarcasm.

Well David, sarcasm does not bode extremely well with written text.

 

[Igor Pirnovar]

Chad Perrin 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.

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

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!

 

[David Masover]

Chad Perrin wrote:


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:irate:erl 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?