I find the perl syntax easier than python

Discussion in 'Perl Misc' started by flifus@gmail.com, Apr 29, 2007.

  1. Guest

    I like perl. I've reading about python lately, which I found a little
    annoying, and, today, I picked up Learning Perl and read a few
    chapters. I like it. I think python is perhaps intended for someone
    who hadn't programmed before, although, personally, I think it
    somewhat fails at that. Perl, on the other hand, for someone who likes
    shell, grep and awk, like I do, seems intuitive.

    I also like the versatility of the syntax. That said, although it's
    versatile, it also seemed consistent.

    Python just annoyed me a little. It was just inconsistent.
     
    , Apr 29, 2007
    #1
    1. Advertising

  2. tuser Guest

    On Apr 29, 8:12 pm, wrote:
    > I like perl.

    So do I.
     
    tuser, Apr 29, 2007
    #2
    1. Advertising

  3. On Apr 29, 11:12 am, wrote:
    > I like perl. I've reading about python lately, which I found a little
    > annoying, and, today, I picked up Learning Perl and read a few


    I find pantyhose annoying.

    > chapters. I like it. I think python is perhaps intended for someone
    > who hadn't programmed before, although, personally, I think it
    > somewhat fails at that. Perl, on the other hand, for someone who likes
    > shell, grep and awk, like I do, seems intuitive.
    >


    This depends on how you view Perl. Perl can be viewed as either
    Procedural or Object Oriented.
    ..
    > I also like the versatility of the syntax. That said, although it's
    > versatile, it also seemed consistent.
    >


    Versalitily isn't always a good thing. This might be stretching the
    realms of funky Perl code, but consider the following two programs
    that will add two numbers.

    #!/usr/bin/perl -w

    sub modify{
    my $value = $_[0] + $_[1];
    print "$value \n";
    }

    my $x = 5;
    my $y = 7;

    modify(5,7);

    and

    #!/usr/bin/perl -w

    sub modify{
    my $first=shift;
    my $second=shift;
    my $value = $first + $second;
    print "$value \n";
    }

    my $x = 5;
    my $y = 7;

    modify(5,7);

    > Python just annoyed me a little. It was just inconsistent.


    In the end, all programming languages are just fagged up versions of
    Lisp. Don't believe it? The following URL makes from some intresting
    late night reading

    http://www.paulgraham.com/icad.html
     
    grocery_stocker, Apr 30, 2007
    #3
  4. On Apr 29, 11:12 am, wrote:
    > I like perl. I've reading about python lately, which I found a little
    > annoying, and, today, I picked up Learning Perl and read a few


    I find pantyhose annoying.

    > chapters. I like it. I think python is perhaps intended for someone
    > who hadn't programmed before, although, personally, I think it
    > somewhat fails at that. Perl, on the other hand, for someone who likes
    > shell, grep and awk, like I do, seems intuitive.
    >


    This depends on how you view Perl. Perl can be viewed as either
    Procedural or Object Oriented paradigm

    > I also like the versatility of the syntax. That said, although it's
    > versatile, it also seemed consistent.
    >

    Versatility isn't always a good thing. Sometimes this can lead to
    stuff being inconsistent. Consider the following code I duped from a
    Google search -).

    #!/usr/bin/perl -w

    use strict;

    sub alter ($) {
    $_[0]= $_[0] . " blub";

    }

    my $s= "bla";

    print "string before: $s \n";
    alter( $s );
    print "string after: $s\n";

    [cdalten@localhost ~]$ ./alter.pl
    string before: bla
    string after: bla blub

    vs

    #!/usr/bin/perl -w

    use strict;

    sub alter ($) {
    my $string = shift;
    $string = $string . " blub";
    }

    my $s= "bla";

    print "string before: $s \n";
    alter( $s );
    print "string after: $s\n";

    [cdalten@localhost ~]$ ./alter.pl
    string before: bla
    string after: bla

    > Python just annoyed me a little. It was just inconsistent.


    In the end, all programming languages are just fagged up versions of
    Lisp. Don't believe it? The following URL makes from some interesting
    late night reading

    http://www.paulgraham.com/icad.html


    Chad
     
    grocery_stocker, Apr 30, 2007
    #4
  5. On 29 Apr 2007 22:08:41 -0700,
    grocery_stocker <> wrote:

    > Versatility isn't always a good thing. Sometimes this can lead to
    > stuff being inconsistent. Consider the following code I duped from a
    > Google search -).
    > #!/usr/bin/perl -w


    > sub alter ($) {
    > $_[0]= $_[0] . " blub";
    >
    > }


    > sub alter ($) {
    > my $string = shift;
    > $string = $string . " blub";
    > }


    I wouldn't call that inconsistent. I can understand that some people
    find it unexpected -- and I could come up with other description for the
    behaviour -- but it's not inconsistent for the following two reasons:

    1 - The code is different, and alters different variables, so there is
    no consistency to violate. The code is not consistent, so there is
    no need for perl to behave in an identical, or even similar, way.

    2 - It's documented to work this way (in perlsub).

    The @_ array is 'magical' in subroutines, and its elements are aliased
    to the scalar parameters to the subroutine call.

    In the second subroutine, you create a lexically scoped local variable,
    which you initialise by copying the contents of the first element of the
    @_ array.


    Note that this sort of aliasing behaviour occurs in only a few places,
    and is documented that way. If you get surprised by it, get in the habit
    never to modify variables unless you know they're local, or you intend
    to modify a global variable.

    Whether it's elegant/desirable for @_ to be aliased this way is a
    separate discussion. For now, we're stuck with it.

    Martien
    --
    |
    Martien Verbruggen | Freudian slip: when you say one thing but
    | mean your mother.
    |
     
    Martien verbruggen, Apr 30, 2007
    #5
  6. On 29 Apr 2007 21:29:54 -0700, grocery_stocker <>
    wrote:

    >Versalitily isn't always a good thing. This might be stretching the
    >realms of funky Perl code, but consider the following two programs
    >that will add two numbers.


    Well, you're right. However there's a remark I always feel like making
    when speaking of Perl's TMTOWTDIness: it's true that there's more than
    one way to do it. But it's also true that for common situations there
    is often a preferred way to do it. Or a few preferred ways, with
    different advantages in different respects. So, if you have e.g. to
    iterate over a range of numbers "the" WTDI is

    for ($MIN..$MAX) { # ...

    and if you have to iterate over a handle, then "the" WTDI is

    while (<$fh>) { # ...

    Please take all this with a grain of salt, of course.

    Perl 6 aims at being even more multiparadigmatic than 5, and to stay
    at the same time consistent. So thanks to lazy evaluation, you will
    e.g. both

    .say for 1..6; # and
    .say for $fh;

    >sub modify{
    > my $value = $_[0] + $_[1];
    > print "$value \n";


    BTW: what is it, with that space?

    >sub modify{
    > my $first=shift;
    > my $second=shift;
    > my $value = $first + $second;
    > print "$value \n";


    These are perfectly equivalent. Both have probably a mischosen name,
    since they do not modify anything, but add and print two numbers. The
    former, for such an easy task, is probably preferable. But in that
    case I would avoid the $value variable altogether.

    Since I mentioned Perl 6 above, in it eventually we will have more
    convenient ways and less ambiguity in passing parameters. We will
    still be able to use @_ & C. but who does really need them when you
    can do

    sub addprint ($n,$m) { say $n+$m } # ?

    (And you would add type declarations for $n and $m if you want to keep
    safe for cheap.)


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, May 2, 2007
    #6
  7. >>>>> "MD" == Michele Dondi <> writes:

    MD> Well, you're right. However there's a remark I always feel
    MD> like making when speaking of Perl's TMTOWTDIness: it's true
    MD> that there's more than one way to do it. But it's also true
    MD> that for common situations there is often a preferred way to
    MD> do it. Or a few preferred ways, with different advantages in
    MD> different respects.

    More concisely: TMTOWTDI, but some ways are better than others.

    Charlton


    --
    Charlton Wilbur
     
    Charlton Wilbur, May 2, 2007
    #7
  8. On 29 Apr 2007 22:08:41 -0700, grocery_stocker <>
    wrote:

    >This depends on how you view Perl. Perl can be viewed as either
    >Procedural or Object Oriented paradigm


    Perl can be viewed as a multiparadigmatic language supporting amongst
    others procedural and object oriented paradigms. It has always been,
    it's become more, it will be even more.

    Now, Perl's current OO model is both weak, due to it being an
    afterthought rather than a primary design choice, and charming for the
    powerful and far reaching consequences it gets out of an extremely
    simple structure constituted by a single "special" function and a tiny
    bag of syntactic sugar. Perl 6's OO'ness will be pervasive but not
    invasive: everything will be an object, but you won't be *forced* to
    think of it as such.

    >> I also like the versatility of the syntax. That said, although it's
    >> versatile, it also seemed consistent.
    >>

    >Versatility isn't always a good thing. Sometimes this can lead to
    >stuff being inconsistent. Consider the following code I duped from a
    >Google search -).


    >sub alter ($) {
    > $_[0]= $_[0] . " blub";
    >
    >}


    This is a well chosen name for a sub that spots a well documented
    charachteristic of the special @_ array to actually modify a value.

    >sub alter ($) {
    > my $string = shift;
    > $string = $string . " blub";
    >}


    This is an example of a sub with a badly chosen name for it uses a
    different parameter passing mechanism that is similarly well
    documented not to be usable to modify a value.

    >> Python just annoyed me a little. It was just inconsistent.


    Actually I would have thought it to be *more* consistent.

    >In the end, all programming languages are just fagged up versions of
    >Lisp. Don't believe it? The following URL makes from some interesting


    Well, not really! ;-)

    >late night reading
    >
    >http://www.paulgraham.com/icad.html


    Indeed!


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, May 2, 2007
    #8
  9. Charlton Wilbur <> wrote:
    >>>>>> "MD" == Michele Dondi <> writes:

    >
    > MD> Well, you're right. However there's a remark I always feel
    > MD> like making when speaking of Perl's TMTOWTDIness: it's true
    > MD> that there's more than one way to do it. But it's also true
    > MD> that for common situations there is often a preferred way to
    > MD> do it. Or a few preferred ways, with different advantages in
    > MD> different respects.
    >
    > More concisely: TMTOWTDI, but some ways are better than others.



    More humorously:

    There are 9 ways to do the same thing in Perl, and 8 of them are no good!


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, May 3, 2007
    #9
  10. On May 2, 1:23 pm, Michele Dondi <> wrote:
    > On 29 Apr 2007 21:29:54 -0700, grocery_stocker <>
    > wrote:
    >
    > >Versalitily isn't always a good thing. This might be stretching the
    > >realms of funky Perl code, but consider the following two programs
    > >that will add two numbers.

    >
    > Well, you're right. However there's a remark I always feel like making
    > when speaking of Perl's TMTOWTDIness: it's true that there's more than
    > one way to do it. But it's also true that for common situations there
    > is often a preferred way to do it. Or a few preferred ways, with
    > different advantages in different respects. So, if you have e.g. to
    > iterate over a range of numbers "the" WTDI is
    >
    > for ($MIN..$MAX) { # ...
    >
    > and if you have to iterate over a handle, then "the" WTDI is
    >
    > while (<$fh>) { # ...
    >
    > Please take all this with a grain of salt, of course.
    >
    > Perl 6 aims at being even more multiparadigmatic than 5, and to stay
    > at the same time consistent. So thanks to lazy evaluation, you will
    > e.g. both
    >
    > .say for 1..6; # and
    > .say for $fh;
    >
    > >sub modify{
    > > my $value = $_[0] + $_[1];
    > > print "$value \n";

    >
    > BTW: what is it, with that space?
    >


    Just a habit I've gotten into.
     
    grocery_stocker, May 3, 2007
    #10
  11. Dr.Ruud Guest

    Michele Dondi schreef:
    > grocery_stocker:


    >> print "$value \n";

    >
    > BTW: what is it, with that space?


    RFC 2646
    ;)

    --
    Affijn, Ruud

    "Gewoon is een tijger."
     
    Dr.Ruud, May 3, 2007
    #11
  12. On 03 May 2007 19:21:12 GMT, Abigail <> wrote:

    >\\ sub addprint ($n,$m) { say $n+$m } # ?
    >
    >And this is an advantage? Limiting yourself to two arguments?


    Well, you know perfectly well that this is an *artificial* example to
    mimic the OP's one. But yes, it's there for those cases in which I
    *do* want to limit myself to two arguments, and perhaps type check
    them.

    >In Perl5, you aren't tempted to use named variables, so you get
    >your arguments in an array. And given an array, it's natural to


    I can't believe you're implicitly assuming that those guys aren't
    thinking of letting you do that in Perl 6 too, and more.

    >allow a variable number of arguments:
    >
    > sub addprint {my $sum = 0; $sum += $_ for @_; print $sum, "\n"}


    Funny, in Perl 6 that could be

    sub addprint {say [+] @_}


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, May 3, 2007
    #12
  13. On Thu, 03 May 2007 21:02:45 GMT, "David Formosa (aka ? the Platypus)"
    <> wrote:

    >So you do something like this
    >
    >sub addprint (*@num) { say [+] @num };


    D'Oh, you beat me. But in my example I showed our friend Abigail that
    if you really want you still have @_.


    Michele
    --
    {$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
    (($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
    ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
    256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
     
    Michele Dondi, May 3, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dm1608
    Replies:
    13
    Views:
    740
    Kevin Spencer
    Feb 24, 2006
  2. b83503104
    Replies:
    5
    Views:
    596
    KC Wong
    May 25, 2004
  3. Ò»Ê×Ê«

    Is there something easier than ORM?

    Ò»Ê×Ê«, Feb 17, 2009, in forum: Python
    Replies:
    13
    Views:
    772
    Kevin Dangoor (Mozilla)
    Feb 26, 2009
  4. Richard
    Replies:
    11
    Views:
    178
    Dr John Stockton
    Aug 7, 2006
  5. Replies:
    0
    Views:
    95
Loading...

Share This Page