Re^3: Perl Vs Ruby

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.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re^3: Perl Vs Ruby

Replies are listed 'Best First'.
Re^4: Perl Vs Ruby by LanX (Saint) on Nov 26, 2008 at 20:23 UTC
Actually I don't trust benchmarks I haven't manipulated by myself! 8 ) ... but I'm a little disappointed you can't point me to a good argument to use ruby. You think that factor 3 doesn't count, but a webadmin might reject to realise his template engine in C. Cheers Rolf	[reply]
Re^5: Perl Vs Ruby by Joost (Canon) on Nov 26, 2008 at 20:26 UTC
See my update :-) Actually, for the foreseeable future, raw CPU speed isn't going to matter as much as good threading/concurrency support. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^6: Perl Vs Ruby by LanX (Saint) on Nov 26, 2008 at 20:43 UTC
Speed is not everything, but with a factor 3 tolerance, one might realize plenty of syntactic sugar and OOP in perl! Things the community normally rejects because of "slowness". e.g. using lvalues and ties for attributes -> A tale about accessors, lvalues and ties Cheers Rolf UPDATE: IMHO, with factor 3 you can completely emulate Ruby within Perl, e.g. with autobox	[reply]
Re^7: Perl Vs Ruby by Joost (Canon) on Nov 26, 2008 at 21:21 UTC
Re^8: Perl Vs Ruby by stvn (Monsignor) on Nov 26, 2008 at 22:23 UTC
Some notes below your chosen depth have not been shown here
Re^8: Perl Vs Ruby by LanX (Saint) on Nov 26, 2008 at 22:25 UTC
Some notes below your chosen depth have not been shown here
Re^4: Perl Vs Ruby by LanX (Saint) on Nov 26, 2008 at 21:25 UTC
I'm no Ruby expert, could you please explain or at least "link" to what you mean with : ) > Perl has less of that, but it does offer a more consistent way of creating and passing functions.	[reply]
Re^5: Perl Vs Ruby by Joost (Canon) on Nov 26, 2008 at 21:55 UTC
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.` [download] 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 }` [download] 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). "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l] [select]


Perl-Sensitive Sunglasses
	PerlMonks