Hi guys,
I teach myself some Perl before I change to Ruby. I am just curious: If
I use the same algorithm to write a Perl and Ruby script, respectively,
which one will run faster? Since everyting in Ruby is object or
reference to an object the script written by Ruby should run faster than
that in Perl’s.
Am I right?
Any comments?
Thanks,
Li
On Sat, 21 Oct 2006, Li Chen wrote:
Hi guys,
I teach myself some Perl before I change to Ruby. I am just curious: If
I use the same algorithm to write a Perl and Ruby script, respectively,
which one will run faster? Since everyting in Ruby is object or
reference to an object the script written by Ruby should run faster than
that in Perl’s.
Am I right?
No.
If you’re looking for a general trend, the trend will be that the Ruby
code will maybe be shorter (if you try to write readable Perl instead of
line noise Perl, it’ll be shorter), it will be far more readable, and
it’ll run more slowly.
There are exceptions, but that will be the observed trend.
Kirk H.
Li Chen wrote:
Hi guys,
I teach myself some Perl before I change to Ruby. I am just curious: If
I use the same algorithm to write a Perl and Ruby script, respectively,
which one will run faster? Since everyting in Ruby is object or
reference to an object the script written by Ruby should run faster than
that in Perl’s.
Am I right?
Another poster has given you the answer, but I am curious about why you
would think that an object-oriented environment would necessarily be
faster
than one that doesn’t have this orientation.
It seems obvious to me that the structure required to suppport an OO
environment does so by sacrificing speed. This relationship is borne out
in
most OO languages to date. The advantage in adopting OO programming
methods
are obvious, but execution speed just isn’t on the list.
At this point, someone might ask what is the point, then? Why have
objects?
The answer is that some programming problems are sufficiently complex
that
either it is not possible to write a reliable program without using OO
principles, or a particular program can’t be written at all using
conventional, pre-OO methods.
Another way of saying this is an unwritable computer program has a very
slow
execution speed.
The proofs of this are all around us. The best example is Windows, which
represents a pastiche of different methods for writing software over
many
years, most of them not remotely structured or object-oriented. The
result
is that Microsoft simply cannot control the code base or reshape it to
meet
new requirements, notwithstanding the fantastic profits that would
accrue
if certain goals were to be achieved. Microsoft has recently had to
simply
give up on certain goals because the code base is in such a sorry state.
Under these circumstances, the code’s execution speed would seem to be a
secondary consideration.
Squeamizh wrote:
Paul L. wrote:
At this point, someone might ask what is the point, then? Why have
objects? The answer is that some programming problems are sufficiently
complex that either it is not possible to write a reliable program
without using OO principles, or a particular program can’t be written at
all using conventional, pre-OO methods.Such as… ?
The next version of Windows, the one that Microsoft had intended to
write, but gave up on, in spite of the billions of dollars in potential
profits. Part of the reason is the well-documented cowboy coder culture
at
Microsoft, and part of it results from the poorly structured code in
present-day Windows.
The crime statistic database that the FBI would love to write, spent
US$170 million dollars trying to write, but failed to write.
The replacement code for the FAA’s traffic control system, which they
spent many millions developing, only to give up on and revert to their
old
code and machines.
Many similar stories. Dozens.
Obviously when I say that such a program can’t be written without using
OO
methods, this is a bit hyperbolic, since these are all examples of
programs
that can be written in principle, but with budget and time constraints,
it
is often not possible in practice.
On 21 Oct 2006, at 00:40, Paul L. wrote:
faster than
that in Perl’s.
Am I right?Another poster has given you the answer, but I am curious about why
you
would think that an object-oriented environment would necessarily
be faster
than one that doesn’t have this orientation.
[snip]
Because some of us have used Eiffel, Smalltalk and Lisp
implementations that are pretty darn speedy 
Hell OO Perl is
speedier than Ruby last time I benchmarked.
Not that I dislike Ruby. It’s fast enough for me, and the decrease in
developer time more than make up for any decrease in execution speed.
That doesn’t mean that Ruby’s speed (or lack thereof) is down to it’s
OO orientation - or that it can’t improve (YARV for example).
Cheers,
Adrian
On 21 Oct 2006, at 07:15, Paul L. wrote:
- The crime statistic database that the FBI would love to write,
Obviously when I say that such a program can’t be written without
using OO
methods, this is a bit hyperbolic, since these are all examples of
programs
that can be written in principle, but with budget and time
constraints, it
is often not possible in practice.
Add to that virtually any government funded large project.
However, I suspect that the poster was looking for examples of
projects that had failed by non-OO methods, but succeeded with OO.
Paul
Paul L. wrote:
At this point, someone might ask what is the point, then? Why have objects?
The answer is that some programming problems are sufficiently complex that
either it is not possible to write a reliable program without using OO
principles, or a particular program can’t be written at all using
conventional, pre-OO methods.
Such as… ?
Paul L. wrote:
- The next version of Windows, the one that Microsoft had intended to
code and machines.Many similar stories. Dozens.
Obviously when I say that such a program can’t be written without using OO
methods, this is a bit hyperbolic, since these are all examples of programs
that can be written in principle, but with budget and time constraints, it
is often not possible in practice.
So, the plural of “anecdote” is “proof” nowadays? OO methodologies
aren’t inherently something that magically makes a software project
“doable” - only when the time constraints are considered this makes
sense. (The overgeneralised blanket statement wasn’t hyperbolic, it was
plain false by itself.)
In my opinion, the OO computation model is successful because it’s more
natural and easier to understand than let’s say the pure functional one
David V.
Adrian H. wrote:
/ …
Because some of us have used Eiffel, Smalltalk and Lisp
implementations that are pretty darn speedy
Yes, but this doesn’t compare their speed to hypothetical non-OO
embodiments
of the same languages (I know this is absurd, just making the point).
Hell OO Perl is
speedier than Ruby last time I benchmarked.
Yes, unfortunately this compares apples and oranges. It doesn’t compare
Perl
with OO Perl, or compare Ruby with a hypothetical non-OO embodiment of
Ruby.
Not that I dislike Ruby. It’s fast enough for me, and the decrease in
developer time more than make up for any decrease in execution speed.
That doesn’t mean that Ruby’s speed (or lack thereof) is down to it’s
OO orientation - or that it can’t improve (YARV for example).
It may well improve over time, but my original point is that producing
an OO
language typically involves some speed sacrifices in exchange for the
advantages of object orientation.
Paul L. wrote:
/ …
However, I suspect that the poster was looking for examples of
projects that had failed by non-OO methods, but succeeded with OO.
I understand. This argument would be difficult to construct, because OO
projects tend not to follow monotonically from their failed, non-OO
predecessors. If a new, successful OO project follows five years after a
disastrous, wasteful non-OO project, would those responsible even be
willing to associate the two?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs