John Carter <john.carter / tait.co.nz> writes:


[...]

> Anyway, I propose that instead of improving arbitary code, the contest
> should aim to improve cookbook code.
> 
> One could then lay the best Ruby rendition of these useful cookbook
> recipes along side the Perl originals and the other languages in Pleac,
> thereby (hopefully) demonstrating Rubies unassailable superiority.

The main problem is what you mean by "best".

In many respects, Perl's CookBook perl code could be ameliorated to make
it "better", or even, "best".

The problem is the didactic approach of this type of code.


For example, in @@PLEAC@@_1.6 we have the following:

irb(main):009:0> long_palindromes = IO.readlines("/usr/share/dict/words").
                   select { |w| w.chomp!; w.reverse == w && w.length > 5 }
["redder", "reviver", "rotator"]


This could be considered as "better" than using File.open("..").readlines
because there is one method call less, and it doesn't get obfuscated.

However, if we imagine IO#readlines would not exist, "optimizing" with
File.open("..").read praising that the results would be still as expected,
would not be very didactic considering the object yielded by read at that
point.


> One could either take Guillaume's code as the "code" to improve.

Most wanted :-). Yet I would still want to examine the code in order to
not commit obfuscated or "too much optimized" stuff.

> Or simply asked Guillaume to suggest "recipes" to Rubify.

Well, 75% are still undone ;p.



-- 
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/