The Problem with Perl

Discussion in 'Perl Misc' started by William Goedicke, Feb 9, 2005.

  1. Dear Y'all -

    As a preferatory note let me say that I've been writing perl for a
    decade or so now and, I love perl. It allows me to concentrate my
    sporadic programming efforts on a single tool because of its breadth
    of functionality.

    I've got some friends whose programming activity is not at all like
    the sporadic hacks that I engage in. They're extremely expert
    programmers with advanced programming degrees from MIT who are
    developing things like tank simulations for the DoD in lisp and other
    more arcane languages. With the one caveat that it may be OK for a
    piker like me who doesn't need to code anything major, they speak of
    perl with utter contempt.

    The point of this message is that I'd like to open a discussion that
    identifies exactly what it is about Perl as a language that offends
    the literati of programming and, respecting that there may be some
    valid points there, how we can code to avoid the problems these issues
    may lead to.

    My best understanding of what they think the problem is that Perl is
    "context sensitive". That is it behaves differently when data
    changes, if lists slip in where scalars were intended the results may
    be wildly different than expected. This wouldn't be true in strongly
    typed languages like C or lisp.

    Do others have knowledge of such (and possibly other) criticisms and,
    what do you think we should do to avoid the associated pitfalls.

    - Billy

    ============================================================
    William Goedicke
    Cell 617-510-7244 http://www.goedsole.com:8080
    ============================================================

    Lest we forget:

    "ff0000" (html for bright red) turns out to be as good
    an indicator of spam as any pornographic term.

    - Paul Graham
     
    William Goedicke, Feb 9, 2005
    #1
    1. Advertising

  2. William Goedicke <> wrote in
    news::

    > As a preferatory note let me say that I've been writing perl for a
    > decade or so now and, I love perl. It allows me to concentrate my
    > sporadic programming efforts on a single tool because of its breadth
    > of functionality.


    Good for you.

    > The point of this message is that I'd like to open a discussion that
    > identifies exactly what it is about Perl as a language that offends
    > the literati of programming


    Oh, please no.

    perldoc -q compare

    Sinan
     
    A. Sinan Unur, Feb 9, 2005
    #2
    1. Advertising

  3. William Goedicke

    D. Marxsen Guest

    "William Goedicke" <> schrieb im Newsbeitrag
    news:...
    ....
    > Do others have knowledge of such (and possibly other) criticisms and,
    > what do you think we should do to avoid the associated pitfalls.


    To me a programming project leader said, perl were "write only language".

    I don't take that comment too serious, as ...

    .... he is a Python fan ...

    .... Perl allows a lot of shortcuts which make it almost unreadable - but you
    can omit these and write wonderful speaking code.
    Speaking of me, my code looks a bit like Pascal - I don't use these fancy
    $_, $. etc. pp. but use the English module any time.
    Then, Perl is as readable as many other languages.


    Just my two cents ...

    Detlef


    PS:
    This topic may offend those who expect pure programming talk in this NG ...
    but it may also be interesting to learn new arguments for defending Perl
    against criticisms.

    --
    D. Marxsen, TD&DS GmbH
    (replace z with h, spam protection)
     
    D. Marxsen, Feb 9, 2005
    #3
  4. Dear Sinan -

    >>>>> "Sinan" == A Sinan Unur <> writes:


    Sinan> William Goedicke <> wrote in
    Sinan> news::

    >> what it is about Perl as a language that offends the literati
    >> of programming


    Sinan> Oh, please no.

    Sinan> perldoc -q compare

    I was hoping for considerably more depth than the perldoc answer,
    semantic theory sort of stuff.

    - Billy

    ============================================================
    William Goedicke
    Cell 617-510-7244 http://www.goedsole.com:8080
    ============================================================

    Lest we forget:

    Happy isn't something you are; it's something you do.

    - William Goedicke
     
    William Goedicke, Feb 9, 2005
    #4
  5. William Goedicke

    Ian Wilson Guest

    William Goedicke wrote:
    > Dear Y'all -
    >
    > As a preferatory note let me say that I've been writing perl for a
    > decade or so now and, I love perl. It allows me to concentrate my
    > sporadic programming efforts on a single tool because of its breadth
    > of functionality.
    >
    > I've got some friends whose programming activity is not at all like
    > the sporadic hacks that I engage in. They're extremely expert
    > programmers with advanced programming degrees from MIT who are
    > developing things like tank simulations for the DoD in lisp and other
    > more arcane languages. With the one caveat that it may be OK for a
    > piker like me who doesn't need to code anything major, they speak of
    > perl with utter contempt.


    Then I suspect they are unlikely to ever change their minds, no matter what.

    > The point of this message is that I'd like to open a discussion that
    > identifies exactly what it is about Perl as a language that offends
    > the literati of programming


    False premise, if at least one person qualifies as literati of
    programming and is not offended by Perl. Could it be that your friends'
    views are not unanimous amongst the "literati?"

    I may be wrong, but "literati" means well-read. Have your friends a good
    understanding of Wall's goals and design decisions for Perl? If asked,
    can they articulate the criteria Wall and others described for their
    design of Perl 5?

    > and, respecting that there may be some
    > valid points there, how we can code to avoid the problems these issues
    > may lead to.
    >


    I feel more relevant questions might be: Who? Should they?

    > My best understanding of what they think the problem is that Perl is
    > "context sensitive". That is it behaves differently when data
    > changes, if lists slip in where scalars were intended the results may
    > be wildly different than expected. This wouldn't be true in strongly
    > typed languages like C or lisp.


    I'm no C programmer but I though bad things (tm) could happen if you
    passed a scalar to a function expecting a pointer to an array?

    I guess, since I am ignorant of it, that Lisp treats everything as
    lists, including zero and single-length lists. I wonder how Lisp behaves
    "if x slips in where y were intended" for all x and y. E.g. strings,
    integers; references, pointers; constants, functions.

    >
    > Do others have knowledge of such (and possibly other) criticisms and,
    > what do you think we should do to avoid the associated pitfalls.
    >


    Little, therefore nothing.
    :)
     
    Ian Wilson, Feb 9, 2005
    #5
  6. Dear Detlef et al -

    >>>>> "Detlef" == D Marxsen <> writes:


    Detlef> ... Perl allows a lot of shortcuts which make it almost
    Detlef> unreadable

    Perl is indeed heavily idiomatic but, if that's only a concern from a
    readibility standpoint then I don't see how any other languages would
    be exempt from the same criticism: python's indentation, lisp's
    parentheses, C's preprocessor constructions. All are hindrances to
    readibility for those who aren't familiar with the language.

    One could argue that idioms are also problematic if they have
    side-effects which aren't clearly expressed in the syntax. Perl makes
    particularly heavy use of this and there are innumerable examples of
    pieces of code which do more than you would reasonably expect and, which
    wouldn't be recognized except by those who've (carefully) read the right
    chapter in the right O'Reily book. (Having said that I've certainly
    dismissed those who haven't as beneath interest on many occasions ;)

    Detlef> PS: This topic may offend those who expect pure
    Detlef> programming talk in this NG ...

    Hopefully members of the group will respect discussions like this as
    "programming talk". It's not *all* about fixing bad hash reference
    syntax.

    - Billy

    ============================================================
    William Goedicke
    Cell 617-510-7244 http://www.goedsole.com:8080
    ============================================================

    Lest we forget:

    "ff0000" (html for bright red) turns out to be as good
    an indicator of spam as any pornographic term.

    - Paul Graham
     
    William Goedicke, Feb 9, 2005
    #6
  7. Ian Wilson <> writes:
    > William Goedicke wrote:
    > > My best understanding of what they think the problem is that Perl is
    > > "context sensitive". That is it behaves differently when data
    > > changes, if lists slip in where scalars were intended the results may
    > > be wildly different than expected. This wouldn't be true in strongly
    > > typed languages like C or lisp.

    >
    > I'm no C programmer but I though bad things (tm) could happen if you
    > passed a scalar to a function expecting a pointer to an array?


    Yes. If you use correct prototypes when compiling, and ask for warnings,
    the compiler will warn. At runtime, you will probably get a core dump.

    > I guess, since I am ignorant of it, that Lisp treats everything as
    > lists, including zero and single-length lists. I wonder how Lisp
    > behaves "if x slips in where y were intended" for all x and
    > y. E.g. strings, integers; references, pointers; constants, functions.


    Not everything is a list in Lisp. There are at least atoms (symbols)
    too, and usually numbers separate from atoms.
    Variables have no opinion at all about the kind of value that will be
    put into them, but a value has a definite type. What the built-in functions
    do with the different kinds of values depend on how sensible it is to
    return a value. Taking the length of a number usually gives an error.
    Some Lisp compilers can generate better code if told that a certain variable
    will only hold values of a certain type.
     
    Arndt Jonasson, Feb 9, 2005
    #7
  8. >>>>> "WG" == William Goedicke <> writes:

    WG> I've got some friends whose programming activity is not at all
    WG> like the sporadic hacks that I engage in. They're extremely
    WG> expert programmers with advanced programming degrees from MIT
    WG> who are developing things like tank simulations for the DoD in
    WG> lisp and other more arcane languages. With the one caveat
    WG> that it may be OK for a piker like me who doesn't need to code
    WG> anything major, they speak of perl with utter contempt.

    Being an expert does not prevent people from holding poorly-informed
    opinions. In fact, being an expert seems to be conducive to holding
    poorly-informed opinions, because an expert can spend a considerable
    amount of time learning about a narrow field and have only the vaguest
    impression of what's going on outside that field.

    WG> Do others have knowledge of such (and possibly other)
    WG> criticisms and, what do you think we should do to avoid the
    WG> associated pitfalls.

    Stop worrying about what other people think. If Perl works well for
    what you need done, use it. If it doesn't, use something else.

    Charlton



    --
    cwilbur at chromatico dot net
    cwilbur at mac dot com
     
    Charlton Wilbur, Feb 9, 2005
    #8
  9. William Goedicke

    Guest

    William Goedicke wrote:

    > My best understanding of what they think the problem is that Perl is
    > "context sensitive". That is it behaves differently when data
    > changes, if lists slip in where scalars were intended the results may
    > be wildly different than expected. This wouldn't be true in strongly
    > typed languages like C or lisp.
    >


    Regarding C and C++, two words: memory leaks.

    I am certain that a strict protocol could be developed within a Perl
    project to ensure the same degree of rigor found in projects done in
    any language.

    I think Perl 6 may resemble Java in a few ways.

    wana
     
    , Feb 9, 2005
    #9
  10. Dear Charlton -

    >>>>> "Charlton" == Charlton Wilbur <> writes:


    Charlton> Stop worrying about what other people think.

    You misunderstood. I'm not worrying; I'm learning.

    - Billy

    ============================================================
    William Goedicke
    Cell 617-510-7244 http://www.goedsole.com:8080
    ============================================================

    Lest we forget:

    The devil's in the details
     
    William Goedicke, Feb 9, 2005
    #10
  11. William Goedicke

    Rhugga Guest

    One thing that has always irritated me about perl is its poor
    implementation of function arguments lists and the way datatypes are
    defined and handled. Being a former C developer this drives me mad. If
    you define a function that takes an int for example:

    foo (int x) {
    // do something
    }

    Thus function calls like these should produce errors: (an error would
    be the function doesn't exist, because in a sense it doesnt)

    foo("some string");
    foo();
    foo(99.99);

    In C/C++ the function foo(int x) and foo(char *) are 2 completely
    different functions, the names may seem similiar to the human reader,
    but deep down inside the nitty gritty these are basically 2 different
    functions.

    foo("some string");
    foo();
    foo(99.99);

    To me this makes perl a very sloppy language and I certainly wouldnt
    use it to process any mission critical data, just leaves to much to
    chance and also in certain situations creates a very difficult
    debugging effort. In the past we have seen things go pear-shaped
    because of this issue when running very high-troughput type stuff.
    Basically your stuck with a massive debug effort with nothing really to
    go on. You end up bloating your code with print statements that output
    debug info and sort it out that way.
     
    Rhugga, Feb 9, 2005
    #11
  12. William Goedicke

    phaylon Guest

    Rhugga wrote:

    > Thus function calls like these should produce errors: (an error would be
    > the function doesn't exist, because in a sense it doesnt)


    Hm, I just made myself a little helper module, where I do:

    sub {
    my($a, $b, $c) = param '_-:%', @_;
    # ...
    }

    This says the parameters are a scalar which must be there (_), one which
    can be undefined (-) and the rest is a hash, which will be referenced in
    $c. Possibilities are d (digit), a (arrayref), h (guess what), and so it
    goes on. I've done this, because prototypes aren't that restricting, and
    to experiment with a bit "off-road-coding".

    The pro against checking the arguments at compile time is that the given
    arguments may vary, which I would miss if it wouldn't be there.

    > You end up bloating your code with print statements that output debug
    > info and sort it out that way.


    If your language doesn't "care" of something that does not mean that you
    also have to ignore it.

    g,phay

    --
    http://www.dunkelheit.at/
    -<[::..::::..::::..]>-
     
    phaylon, Feb 9, 2005
    #12
  13. William Goedicke

    Guest

    "Rhugga" <> wrote:
    > One thing that has always irritated me about perl is its poor
    > implementation of function arguments lists and the way datatypes are
    > defined and handled. Being a former C developer this drives me mad. If
    > you define a function that takes an int for example:
    >
    > foo (int x) {
    > // do something
    > }
    >
    > Thus function calls like these should produce errors: (an error would
    > be the function doesn't exist, because in a sense it doesnt)
    >
    > foo("some string");
    > foo();
    > foo(99.99);
    >
    > In C/C++ the function foo(int x) and foo(char *) are 2 completely
    > different functions, the names may seem similiar to the human reader,
    > but deep down inside the nitty gritty these are basically 2 different
    > functions.
    >
    > foo("some string");
    > foo();
    > foo(99.99);
    >
    > To me this makes perl a very sloppy language and I certainly wouldnt
    > use it to process any mission critical data, just leaves to much to
    > chance and also in certain situations creates a very difficult
    > debugging effort. In the past we have seen things go pear-shaped
    > because of this issue when running very high-troughput type stuff.


    Why would the throughput matter? If your input is garbage, it doesn't
    matter how much of it there is.

    > Basically your stuck with a massive debug effort with nothing really to
    > go on.


    You mean other than the warnings that tell you that you used a non-numeric
    string as if it were a number at line 1087?

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Feb 9, 2005
    #13
  14. William Goedicke

    Guest

    William Goedicke <> wrote:

    >
    > My best understanding of what they think the problem is that Perl is
    > "context sensitive". That is it behaves differently when data
    > changes,


    Well duh. What good would a program be that didn't?

    > if lists slip in where scalars were intended the results may
    > be wildly different than expected. This wouldn't be true in strongly
    > typed languages like C or lisp.


    I don't think it is generally true in Perl, either. It is the code,
    not the data, that determines list or scalar context.

    > Do others have knowledge of such (and possibly other) criticisms and,
    > what do you think we should do to avoid the associated pitfalls.


    Pay attention to what you are coding!

    The biggest problem I run into in Perl is its time and memory usage in
    certain areas. After that, most of the problems are political. Vendors
    and consultants don't talk up Perl because it doesn't help them sell stuff.

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Feb 9, 2005
    #14
  15. William Goedicke

    Anno Siegel Guest

    William Goedicke <> wrote in comp.lang.perl.misc:

    [Perl as a programming language]

    > My best understanding of what they think the problem is that Perl is
    > "context sensitive".




    In what sense? "Context sensitive" is a term that applies to grammars
    (and, by extension, to parsers).

    Perl can't be parsed as a context-free grammar? You bet it can't. Neither
    can Fortran, or, AFAIK, C. I don't know about C for sure, but I'd be
    surprised. This property of a grammar has little to do with the practical
    usability of the programming language.

    Perl also has the concept of (list/scalar/void-) context pertaining to
    various parts of the source, but describing this as being "context
    sensitive" is abuse of terminology.

    > That is it behaves differently when data
    > changes,


    So? C and Lisp programs don't do that?

    > if lists slip in where scalars were intended the results may
    > be wildly different than expected. This wouldn't be true in strongly
    > typed languages like C or lisp.


    Lisp is a typed language? I never noticed.

    This critique of Perl contains so many ill-conceived notions, it is hard
    to take it serious.

    Anno
     
    Anno Siegel, Feb 9, 2005
    #15
  16. William Goedicke <> wrote:
    >>>>>> "Sinan" == A Sinan Unur <> writes:



    > Sinan> perldoc -q compare
    >
    > I was hoping for considerably more depth than the perldoc answer,
    > semantic theory sort of stuff.



    Like why Larry designed Perl the way he did?

    http://www.wall.org/~larry/natural.html


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Feb 9, 2005
    #16
  17. William Goedicke

    Eric Bohlman Guest

    -berlin.de (Anno Siegel) wrote in
    news:cudo1a$1vj$-Berlin.DE:

    > Perl can't be parsed as a context-free grammar? You bet it can't.
    > Neither can Fortran, or, AFAIK, C. I don't know about C for sure, but
    > I'd be surprised. This property of a grammar has little to do with


    It can't. C requires that functions be called with the same number of
    parameters they're declared with, and that can't be expressed in a CFG.
     
    Eric Bohlman, Feb 9, 2005
    #17
  18. >>>>> "WG" == William Goedicke <> writes:

    >>>>> "Charlton" == Charlton Wilbur <> writes:


    Charlton> Stop worrying about what other people think.

    WG> You misunderstood. I'm not worrying; I'm learning.

    Well, if you want to learn, ask the people who disparage Perl why they
    do so. Odds are you'll find, if you can dig below the surface, that
    it's most likely based on inaccurate information, experience with a
    disastrous Perl project, or adherence to some orthodox One True Way to
    Program.

    Perl does have weaknesses. In particular, it is flexible enough that
    in the hands of poor programmers it can be disastrous for large
    products. This is an intentionally chosen tradeoff, however: if the
    language enforces a certain discipline on its programmers, then
    programmers who are capable of imposing different discipline on
    themselves find the language frustrating to use (though programmers
    who would otherwise have no discipline benefit greatly). A bad
    programmer using Perl can create more disasters for other people to
    clean up than a bad programmer using just about any other language,
    because Perl is so flexible and forgiving -- and I've left jobs before
    because I knew that if I stayed I'd get to deal with cleaning up Perl
    messes; but I don't ascribe that to the language, but to the
    programmer using it.

    Perl is also not aesthetically pure. It's not a purely functional
    language, it's not a purely object-oriented language; it's not a
    purely minimalist close-to-the-machine language. It has aspects of
    all of them, though. It wasn't designed from the start with a single
    vision; it grew in bits and pieces. This lack of purity -- hybrid
    vigor, one might say -- is one of its greatest strengths, because
    there are many ways to solve any particular problem. But when you
    compare it to the purebred Scheme and Eiffel and Smalltalk --
    languages that academics are likely to have used disproportionately
    more than the hoi polloi -- it looks like a mongrel.

    All that said, if you want to understand why your colleages disparage
    Perl, ask them. Odds are that the people who disparage Perl, aside
    from the odd troll, are not hanging out in comp.lang.perl.misc just
    waiting for an opportunity to explain themselves.

    Charlton



    --
    cwilbur at chromatico dot net
    cwilbur at mac dot com
     
    Charlton Wilbur, Feb 9, 2005
    #18
  19. William Goedicke

    Eric Bohlman Guest

    Charlton Wilbur <> wrote in
    news::

    > Perl does have weaknesses. In particular, it is flexible enough that
    > in the hands of poor programmers it can be disastrous for large
    > products. This is an intentionally chosen tradeoff, however: if the
    > language enforces a certain discipline on its programmers, then
    > programmers who are capable of imposing different discipline on
    > themselves find the language frustrating to use (though programmers
    > who would otherwise have no discipline benefit greatly). A bad


    This is a really important point. Perl shouldn't be thought of as an
    "undisciplined language"; it should be thought of as a "bring your own
    discipline (BYOD) language." Larry's philosophy is that programming
    discipline is a human issue, not a technical one, and therefore needs to be
    enforced by human (social) means, not through technical characteristics of
    tools.
     
    Eric Bohlman, Feb 9, 2005
    #19
  20. [A complimentary Cc of this posting was sent to
    Charlton Wilbur
    <>], who wrote in article <>:

    > Perl does have weaknesses. In particular, it is flexible enough that
    > in the hands of poor programmers it can be disastrous for large
    > products. This is an intentionally chosen tradeoff, however


    There is very little "intentionally chosen" in Perl; design-wise Perl
    is a hodge-podge of backward-compatibility hacks and incremental
    development mess. (It still has some advantages over competition in
    other respects - but only for some people; people who cann't fight
    their vomit reflex are not in a reasonable state for good coding.)

    Compare with what you write below:

    > all of them, though. It wasn't designed from the start with a single
    > vision; it grew in bits and pieces.


    Hope this helps.
    Ilya
     
    Ilya Zakharevich, Feb 9, 2005
    #20
    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. dpackwood
    Replies:
    3
    Views:
    1,829
  2. PerlFAQ Server

    FAQ 1.4 What are Perl 4, Perl 5, or Perl 6?

    PerlFAQ Server, Jan 23, 2011, in forum: Perl Misc
    Replies:
    0
    Views:
    313
    PerlFAQ Server
    Jan 23, 2011
  3. PerlFAQ Server
    Replies:
    0
    Views:
    703
    PerlFAQ Server
    Feb 3, 2011
  4. PerlFAQ Server

    FAQ 1.4 What are Perl 4, Perl 5, or Perl 6?

    PerlFAQ Server, Feb 27, 2011, in forum: Perl Misc
    Replies:
    0
    Views:
    308
    PerlFAQ Server
    Feb 27, 2011
  5. PerlFAQ Server
    Replies:
    0
    Views:
    708
    PerlFAQ Server
    Apr 4, 2011
Loading...

Share This Page