[ruby-talk:03652] Re: Perl and Ruby: an Irony

Hi,

Dat Nguyen wrote:

> I am rewriting a Perl program in Ruby to see the difference.
> Follows is a segment of the Perl program:
>
> while (<>) {
>         if (/1999/) {
>                 ($date, $hour, $name, $id) = split;
>                 print "$date:$hour:$name:$id\n"
>         }
> }
>
> And follows is the counterpart in Ruby:
>
> while(gets())
>         if /1999/
>                 date, hour, name, id = split
>                 print "#{date}:#{hour}:#{name}:#{id}\n"
>         end
> end
>
> I am not sure which one, Perl or Ruby, is more readable here. This is a
> curious observation: to get rid of the $ on one line, one has to pay #{} on
> the following line. Is this the principle "pay it now, or pay it later ...
> with interest!" ?

No, this is an example of (1) the fallacy of generalizing from one data point
(or, more generally, of generalizing from unrepresentative or incompletely
representative data samples), of (2) the fallacy of false presumption, and of
(3) overlooking what you almost certainly already know.

To reiterate the obvious, programming languages are designed as systems, not as
independent collections of "atomic" features. (We are talking about so-called
high level general purpose languages such Smalltalk, Perl, Ruby, Python, and
Java here.) Such programming languages are designed for a wide range of
applications that span many degrees of complexity. Their features are not
(typically) selected in isolation and out of this overall context, but rather
with the aim of providing a useful overall system, subject to whatever
tradeoffs those involved deem best overall. Building blocks that are too simple
often make moderately-to-substantially complex things much more cumbersome.
Uniformity and overall simplicity are often compromised under such conditions
as well.

You don't have too look very far to find more complicated cases of Perl
interpolation. Indeed there are lots of  things in Perl that are initially very
convenient and compact for simple tasks, but which tend to become increasingly
counterintuitive and messier for more sophisticated tasks.

--
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)