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
--
Posted via http://www.ruby-forum.com/.
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 Haines
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?
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.
--
Paul Lutus
http://www.arachnoid.com
Paul Lutus 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... ?
[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 00:40, Paul Lutus wrote:
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.
Squeamizh wrote:
Paul Lutus 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... ?
1. 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.
2. The crime statistic database that the FBI would love to write, spent
US$170 million dollars trying to write, but failed to write.
3. 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.
--
Paul Lutus
http://www.arachnoid.com
Adrian Howard 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 Lutus
http://www.arachnoid.com
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
On 21 Oct 2006, at 07:15, Paul Lutus wrote:
Squeamizh wrote:
Paul Lutus 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... ?
1. 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.2. The crime statistic database that the FBI would love to write, spent
US$170 million dollars trying to write, but failed to write.3. 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.
Paul Lutus wrote:
Squeamizh wrote:
Paul Lutus 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... ?
1. 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.2. The crime statistic database that the FBI would love to write, spent
US$170 million dollars trying to write, but failed to write.3. 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.
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
- notably so when you consider the more high-level abstractions. This
makes it easier to become "qualified enough" to solve a given problem
and maintain an OO solution. (Paul Graham might or might not object ;P)
David Vallner
Paul Lynch 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?
--
Paul Lutus
http://www.arachnoid.com