|
Re^3: Perl Vs Ruby
by Joost (Canon) on Nov 26, 2008 at 20:13 UTC
|
A factor 3 isn't really that much of a difference, considering that with both languages you can/must switch to C/C++ for CPU-heavy work, which will fairly easily give you a factor 20 .. 100 speed increase, depending on the problem.
update: I might as well throw my opinion on Perl vs Ruby in here.
Ruby is slower than Perl, but neither should be used if pure raw speed is your ultimate goal.
Ruby has some nice idioms in the core library that are open for anyone to use and extend. Ruby's iterator/collection idioms are particularly nice compared to perl's mess of for(each) / while ... keys ... / whatever interface some CPAN module implements.
Perl has a larger range of modules in CPAN. Ruby modules are not organized in one place, so that means it's harder to find good quality extensions that do what you need.
Ruby's built-in OO interface is a LOT better than Perl's (which probably also explains why perl's standard collections suck so much).
Ruby has reasonably nice syntactic sugar for functional constructs. Perl has less of that, but it does offer a more consistent way of creating and passing functions.
Neither language has serious threading support - though Perl's ithreads are fairly easy to integrate with C/C++ pthreaded code.
Personally, if I wanted to create something large using a lot of OO that's not all that CPU critical, I'd probably go for Ruby over Perl, because Ruby looks better (especially OO code). If it also needs to be FAST, I don't know what I'd use - Common Lisp maybe, or Java, or C++, or possibly Clojure.
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
|
|
|
| [reply] |
|
|
Perl has a single operator to create functions: sub, which is used to create named functions and (anonymous) function refs. It also has some syntactic sugar in that you can create a prototype that takes as it's first argument a function ref, by calling
some_function_with_ref_prototype { |params| do_something_with params }
+ "bla", $foo.
Note that the sugar looks great when you want to re-implement something matching grep or map as defined in the perl core but not for more interesting stuff like if or when constructs. It also immediately breaks down if you want to use OO, since prototypes aren't supported on methods.
In ruby every function is a method, and functions can create some special sugar that allows you to use a code block as the last element. Once you've seen it it's apparent that this variant is much more useful, especially since the ruby core uses the same construct for a lot of stuff that's "special" in perl, like iterators:
some_array.each { |element|
# do something with element
}
For more examples, see the Enumerable module, which is used by pretty much every collection-type object in Ruby - meaning you can use each/map/grep/etc on every object that implements only a few primitive methods and includes that module (or doesn't include the module but implements the map/grep/etc methods itself).
The "problem" is, that ruby makes it slightly harder to pass named functions as blocks/procs, because blocks there have special scoping/lookup rules (since they're not methods).
See Proc vs Method for example (I don't think blocks are first-class objects).
| [reply]
[d/l]
[select] |
Re^3: Perl Vs Ruby
by ptoulis (Scribe) on Nov 27, 2008 at 00:02 UTC
|
The last benchmark I saw showed a factor 3 difference
Do you really consider a 6,000-times-repeated call of one function, on a 500MHz machine, to be a language benchmark? Please, don't.
| [reply] |
|
|
| [reply] |
|
|
Language benchmarks are in general irrelevant and stupid. If you insist try this link for some more.
Ruby has a dynamic type system, you can add methods to an object on the fly.This makes it slow, but this is also why it has Rails.
What's the point of the benchmark again?
| [reply] |
|
|
|
|
|