Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Perl losing, unfairly

by meetraz (Hermit)
on Jun 15, 2004 at 03:45 UTC ( [id://366759]=perlmeditation: print w/replies, xml ) Need Help??

A recent slashdot article mentions this contest which compares features and "program length" of various languages. I expected to see perl win, but it's currently in third place. Without resorting to obfuscation, I think perl could easily win this comparison. A lot of the scripts on the site are (unfairly) too long. Examples:

hello world: perl -le 'print "Hello World"'
should be: print 'Hello World' (code fragment like the other languages, not command line)

print first arg: perl -le 'print $ARGV[0]'
should be: print shift

I think we should send the author of this site the proper perl scripts and make sure perl comes out on top.

Replies are listed 'Best First'.
Re: Perl losing, unfairly
by jepri (Parson) on Jun 15, 2004 at 04:04 UTC
    You should definately mail him, but don't get too worked up.

    It's just Yet Another Example of someone doing an opinion piece and dressing it up so he doesn't look as clueless as he is. He's assigned weighted scores to qualitative values, he's arbitrarily picked language features to compare, and worst of all, he's presented numeric scores like they actually mean anything at all.

    As a 'here's how to do XXX in 20 different languages' it's actually not bad. As a comparison piece, it's clearly a waste of time.

    As for Perl coming out on top, have a look at Paul Graham's pieces on good languages.

    I didn't believe in evil until I dated it.

Re: Perl losing, unfairly
by perrin (Chancellor) on Jun 15, 2004 at 05:13 UTC
    The trouble with trying to win a contest based on program length is that it will lead you to write nasty code that reinforces people's opinions about Perl being hard to read. The first things to go in Perl golf are "use strict" and "use warnings", which is not something I want to see when trying to demonstrate that Perl is mature enough to be used for serious projects. (I know, the example given above is entirely reasonable, but "I can make my program shorter" is a slippery slope.)
Write the author
by PodMaster (Abbot) on Jun 15, 2004 at 05:45 UTC
    You should write the author. That perl -le"" stuff should definetly go. I wrote him a couple of times already.

    PS - This has already been discussed here (i think, maybe just in chatterbox) and on (for sure).

    update: s{-e "/etc/mtab" or exit 1}{exit !-e "/etc/mtab"} s{-r "/etc/mtab" or exit 1}{exit !-r "/etc/mtab"}

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

Re: Perl losing, unfairly
by dreadpiratepeter (Priest) on Jun 15, 2004 at 12:00 UTC
    Actually, before you get you panties in a twist, notice that he is not adding the whole invocation to the count, only the -le characters. Thus his count isn't off, and replacing the -le with ,"\n" is actually longer, and ,$/ is a wash.
    Actually looking through the examples he seems to be pretty non-biased. All the examples use the same whitespacing between tokens, and they all seem to be written efficiently with being obsfucated. My only question is whether sed and awk can be considered part of shell. I.E. if shell can use sed and awk in it's scripts, couldn't some of the other languages get a win by using system to call out to sed or awk (or Perl)?

    "Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."

      I mailed the author with some issues and have recieved a reply. One part is relevent to what you just said:

      i fixed. For example, for   % perl -le 'print $ARGV[0]' i take the length of   -l print $ARGV[0]

      But the fact remains that he has NOT been generous to Perl. In fact the way I read the code hes been ungenerous to perl. Consider all the examples that involve or exit 1 (which is not normal idion to return an error value to the OS in perl, unless that error MUST specifically be 1, any sane programmer would use die,) or the fact that in many of the examples he includes the invocation in the perl examples but not in any of the other examples.

      But what really gets me is the File::Find example. His code reads to me the way someone would write it if they deliberately want to disadvantage perl.

      use File::Find; find({ no_chdir => 1, wanted => sub { if (($o = $_) =~ s/\.c$/.o/ && -M $_ <= -M $o) { print "compiling $_ to $o\n"; system qw(gcc -c -o), $o, $_; } } }, '.');

      Why the no_chdir here, or the options hash at all?

      use File::Find; find sub { if (($a = $_) =~ s/\.c$/.o/ && -M $_ <= -M $a) { print "compiling $_ to $a\n"; system qw(gcc -c -o), $a, $_; } }, '.';

      So, by my reading of this once these changes are made Perl wins.


        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi

        Actually, I missed that in the File::Find example. In fact either the Perl test (and some others) is invalid or the shell test (and some others) is.
        The shell script compiles recursively, and the Perl has a check to avoid compiling recursively. One of them violates the goal of the script

        As far as the exit stuff goes, I realized that it could be written better as:
        exit !-e "/etc/mtab"
        I emailed the author with the exit changes (and reiterated your File::Find findings). Hopefully he will resolve them.

        "Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."
Re: Perl losing, unfairly
by hv (Prior) on Jun 15, 2004 at 11:19 UTC

    Your example replacements are insufficient, because in those cases the string must be printed with a newline.

    For 'print first arg', for example, it should be:

    print shift, "\n" (or maybe: print "$ARGV[0]\n" )
    giving a length of 17 (or maybe 18), exactly the same as (or maybe more than) the score attributed. In the context of a larger program neither '-l' nor 'shift' would likely be reasonable, so you could say the writer has been generous to perl here.


      print shift,$/;
Re: Perl losing, unfairly
by tbone1 (Monsignor) on Jun 15, 2004 at 13:15 UTC
    You know, you really shouldn't get too worked up about these things. Generally speaking, the kind of people who do those sorts of contests are people without enough skill to get paid to spend their time doing the thing they are allegedly experts in.

    (Note to self: try to make that sentence run on even longer ...)

    tbone1, YAPS (Yet Another Perl Schlub)
    And remember, if he succeeds, so what.
    - Chick McGee

Re: Perl losing, unfairly
by zentara (Archbishop) on Jun 15, 2004 at 12:08 UTC
    I can't believe that bash shell wins this contest. Yeah, sh scripts are handy, but Perl is far more useful, and readable.

    I'm not really a human, but I play one on earth. flash japh
      Really, it's combining bash and perl that is great fun. for example:
      [me@host]$ more `which whichpm` #!/bin/sh perl "-M$1" -le '$_=shift; s|::|/|g; print $INC{"$"}' "$1" [me@host]$
      Writing 'whichpm' in perl alone would take a fair bit more space.

      And everyone knows that I love perl command line switches :-D

      ------------ :Wq Not an editor command: Wq
        Or just: perldoc -l
        $ alias whichpm='perldoc -l' $ whichpm HTML::Template /usr/lib/perl5/site_perl/5.8.0/HTML/


Re: Perl losing, unfairly
by eric256 (Parson) on Jun 15, 2004 at 14:48 UTC

    Since it states that its realy competetion of script features of programming and perl actualy ties for second falling only a point short of tie for first it looks quite fair. Some of the perl code isn't what you might right, but i'm willing to bet the same holds true for other languages on that list. All in all I think its interesting but I don't think anyone is going to choose what to program in based on that.

    Eric Hodges
Re: Perl losing, unfairly
by Steve_p (Priest) on Jun 16, 2004 at 02:50 UTC

    These types of contests cannot be truly done by one individual unless that person is an expert in all the languages tested. We did a head to head at work once, and took the same set of requirements and two of us wrote the programs in two separate languages. First to meet all the requirements won. Trying to have the same programmer do the same thing just doesn't work since their biases and knowledge (or lack thereof) get in the way of the competition being fair. You tend to get the results you wanted in the first place.

Re: Perl losing, unfairly
by zentara (Archbishop) on Jun 16, 2004 at 12:22 UTC
    Here is a better wriiten article on bash and perl scripting, which is better rooted in reality. Scripting for Sysadmins

    I'm not really a human, but I play one on earth. flash japh

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://366759]
Approved by davido
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (3)
As of 2024-04-16 21:32 GMT
Find Nodes?
    Voting Booth?

    No recent polls found