to RG - Lisp lunacy and Perl psychosis

Discussion in 'Perl Misc' started by ccc31807, Mar 10, 2010.

  1. ccc31807

    ccc31807 Guest

    On February 27, in a thread on c.l.l, RG had this to say about Perl:
    <quote>
    >> But Perl is just an
    >> abomination through-and-through. I do not deny that many people find it
    >> a productive tool, and about ten years ago having developed a certain
    >> level of respect for some of those people I determined to learn Perl
    >> just to see what those people got out of it. So I picked up a Perl
    >> book, but I could not get past the first few chapters without recoiling
    >> in revulsion. It was just horrible.

    </quote>
    I wanted to reply but also wanted to take some time to think about my
    reply.

    Yesterday, I wrote a typical data munging script using Perl. I was
    using two hashes, %sec and %fac, and needed to populate the 'location'
    value in %fac with the value in %sec depending on the state of the
    'xlist' key in %sec. The code looks horrible, but I think any
    journeyman programmer can follow the logic even if he doesn't
    understand Perl or the data structures. This is the code, and I might
    add that it's working code:

    <code>
    if ($sec{$k}{'xlist'} !~ /\d/)
    { $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
    elsif ($sec{$k}{'xlist'} eq $sec{$k}{'crs_id'})
    { $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
    else
    { $fac{$sec{$k}{'id1'}}{'location'} = $sec{$sec{$k}{'xlist'}}
    {'site'}; }
    </code>

    In David Lamkins' book 'Successful Common Lisp' in chapter 4, we find
    the following. This also looks horrible, and I don't think a
    journeyman programmer can follow this logic unless he knew something
    about Lisp.

    <quote>
    The following piece of code illustrates how you can use the same name
    for different purposes. Take a minute to read this, and see how many
    separate uses you can count for the name FUNNY.

    (defun funny (funny)
    "funny..."
    (if (zerop funny)
    :funny
    (list
    (cons funny
    (let ((funny funny))
    (setq funny (1- funny))
    (funny funny)))
    funny)))

    Here are the five roles played by this one name:

    1. function name
    2. function argument
    3. a word in the documentation string
    4. a constant in the keyword package
    5. a new lexical variable
    </quote>

    Perl uses sigils ($, !, %, &) to signify a token's usage. Lisp uses
    positional notation for the same thing. It's not that one's bad and
    one's not -- it's just cosmetic. It's as if one language is wearing a
    pinstripe suit with wing tips and the other is wearing a blue blazer
    with penny loafers. Underneath, the logic is the same in both
    languages, and once you get past the peculiarities of the language you
    use the same logic. (I'm not arguing that the power of the languages
    is the same, in several respects Lisp is more powerful than Perl, but
    that the process of thinking through a problem is the same.)

    Here's the point: to call one language horrible and an abomination
    because you don't understand it, and ignoring the horribleness and the
    abominable in another language because you do understand it, doesn't
    make any sense. The cover doesn't make the book the clothes don't make
    the man, and the appearance doesn't make the language. Instead, a
    language should be judged on the work that it permits, and in this
    respect (based on surveys like TIOBE and advertised positions) Perl
    seems to be a lot more useful (and perhaps a lot less horrible) than
    CL.

    One language isn't better or worse that the other, they are just
    different, and the expression of RG's opinion is simply a value
    judgment, which others may or may not share.

    CC.
    ccc31807, Mar 10, 2010
    #1
    1. Advertising

  2. ccc31807

    Tamas K Papp Guest

    On Wed, 10 Mar 2010 07:01:14 -0800, ccc31807 wrote:

    > (defun funny (funny)
    > "funny..."
    > (if (zerop funny)
    > :funny
    > (list
    > (cons funny
    > (let ((funny funny))
    > (setq funny (1- funny))
    > (funny funny)))
    > funny)))
    >
    > Here are the five roles played by this one name:
    >
    > 1. function name
    > 2. function argument
    > 3. a word in the documentation string 4. a constant in the keyword
    > package
    > 5. a new lexical variable


    You mean that you can use something as a variable name, and then use
    the same letters as part of a string? Gosh, Common Lisp must be Pure
    Madness!

    But more seriously, you completely misunderstand Common Lisp when you
    write "roles played by this ONE NAME" (my emphasis). It is _not_ one
    name.

    Your post actually highlights some similarities between Perl and CL:
    both have various namespaces, once you see through the thin layer of
    syntax for accessing these. So your feeble attempt at starting a
    flamewar is pretty... funny.

    Tamas
    Tamas K Papp, Mar 10, 2010
    #2
    1. Advertising

  3. ccc31807

    ccc31807 Guest

    On Mar 10, 10:46 am, Tamas K Papp <> wrote:
    > So your feeble attempt at starting a flamewar is pretty... funny.


    Not my intent to start a flame war. Please reread my post.

    > Here's the point: to call one language horrible and an abomination
    > because you don't understand it, and ignoring the horribleness and the
    > abominable in another language because you do understand it, doesn't
    > make any sense.


    CC
    ccc31807, Mar 10, 2010
    #3
  4. ccc31807

    Tamas K Papp Guest

    On Wed, 10 Mar 2010 07:53:28 -0800, ccc31807 wrote:

    > On Mar 10, 10:46 am, Tamas K Papp <> wrote:
    >> So your feeble attempt at starting a flamewar is pretty... funny.

    >
    > Not my intent to start a flame war. Please reread my post.


    Yeah, sure. Cross-posting something like this usually promotes peace
    and happiness.

    >> Here's the point: to call one language horrible and an abomination
    >> because you don't understand it, and ignoring the horribleness and the
    >> abominable in another language because you do understand it, doesn't
    >> make any sense.


    You failed to show anything horrible or abominable in CL. All you
    demonstrated was your confusion (but that was done pretty well,
    congrats).

    Cheers,

    Tamas
    Tamas K Papp, Mar 10, 2010
    #4
  5. ccc31807

    Peter Keller Guest

    In comp.lang.lisp ccc31807 <> wrote:
    > Perl uses sigils ($, !, %, &) to signify a token's usage.


    That's not entirely true.

    Example:

    # BEGIN CODE
    #! /usr/bin/perl

    $foo = 12;
    $foo{'key'} = 34;
    $foo[9] = 55;

    print "$foo $foo{'key'} $foo[9]\n";
    exit 0;
    # END CODE

    C has similar problems between type names and functions:

    /* Begin Code */
    #include <stdio.h>
    #include <stdlib.h>

    struct XXX
    {
    int foo;
    };

    void XXX(void)
    {
    printf("Hello world\n");
    }

    int main(void)
    {
    struct XXX fg;

    XXX();

    return 0;
    }
    /* End Code */

    Nearly all languages have different namespaces for their semantic ideas:
    functions, types, variables, etc, etc, etc. Symbols often intersect
    in representation: the symbol 'foo' in one namespace is identical to
    the symbol 'foo' in another namespace. They rarely, but sometimes do
    depending on the language, intersect in meaning.

    An example is calling a higher order function in scheme versus lisp.
    In scheme you simply call it, in lisp, you use funcall.

    Later,
    -pete
    Peter Keller, Mar 10, 2010
    #5
  6. ccc31807

    Ron Garret Guest

    Most of what I have to say about this has already been said by other
    people, but since this post is addressed specifically to me I'll respond
    nonetheless.

    In article
    <>,
    ccc31807 <> wrote:

    > On February 27, in a thread on c.l.l, RG had this to say about Perl:
    > <quote>
    > >> But Perl is just an
    > >> abomination through-and-through. I do not deny that many people find it
    > >> a productive tool, and about ten years ago having developed a certain
    > >> level of respect for some of those people I determined to learn Perl
    > >> just to see what those people got out of it. So I picked up a Perl
    > >> book, but I could not get past the first few chapters without recoiling
    > >> in revulsion. It was just horrible.

    > </quote>
    > I wanted to reply but also wanted to take some time to think about my
    > reply.
    >
    > Yesterday, I wrote a typical data munging script using Perl. I was
    > using two hashes, %sec and %fac, and needed to populate the 'location'
    > value in %fac with the value in %sec depending on the state of the
    > 'xlist' key in %sec. The code looks horrible, but I think any
    > journeyman programmer can follow the logic even if he doesn't
    > understand Perl or the data structures. This is the code, and I might
    > add that it's working code:
    >
    > <code>
    > if ($sec{$k}{'xlist'} !~ /\d/)
    > { $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
    > elsif ($sec{$k}{'xlist'} eq $sec{$k}{'crs_id'})
    > { $fac{$sec{$k}{'id1'}}{'location'} = $sec{$k}{'site'}; }
    > else
    > { $fac{$sec{$k}{'id1'}}{'location'} = $sec{$sec{$k}{'xlist'}}
    > {'site'}; }
    > </code>
    >
    > In David Lamkins' book 'Successful Common Lisp' in chapter 4, we find
    > the following. This also looks horrible, and I don't think a
    > journeyman programmer can follow this logic unless he knew something
    > about Lisp.
    >
    > <quote>
    > The following piece of code illustrates how you can use the same name
    > for different purposes. Take a minute to read this, and see how many
    > separate uses you can count for the name FUNNY.
    >
    > (defun funny (funny)
    > "funny..."
    > (if (zerop funny)
    > :funny
    > (list
    > (cons funny
    > (let ((funny funny))
    > (setq funny (1- funny))
    > (funny funny)))
    > funny)))
    >
    > Here are the five roles played by this one name:
    >
    > 1. function name
    > 2. function argument
    > 3. a word in the documentation string
    > 4. a constant in the keyword package
    > 5. a new lexical variable
    > </quote>
    >
    > Perl uses sigils ($, !, %, &) to signify a token's usage. Lisp uses
    > positional notation for the same thing. It's not that one's bad and
    > one's not -- it's just cosmetic. It's as if one language is wearing a
    > pinstripe suit with wing tips and the other is wearing a blue blazer
    > with penny loafers. Underneath, the logic is the same in both
    > languages, and once you get past the peculiarities of the language you
    > use the same logic. (I'm not arguing that the power of the languages
    > is the same, in several respects Lisp is more powerful than Perl, but
    > that the process of thinking through a problem is the same.)
    >
    > Here's the point: to call one language horrible and an abomination
    > because you don't understand it, and ignoring the horribleness and the
    > abominable in another language because you do understand it, doesn't
    > make any sense. The cover doesn't make the book the clothes don't make
    > the man, and the appearance doesn't make the language. Instead, a
    > language should be judged on the work that it permits, and in this
    > respect (based on surveys like TIOBE and advertised positions) Perl
    > seems to be a lot more useful (and perhaps a lot less horrible) than
    > CL.
    >
    > One language isn't better or worse that the other, they are just
    > different, and the expression of RG's opinion is simply a value
    > judgment, which others may or may not share.


    Certainly my opinion is only my opinion. But in my opinion it is not
    true that "one language isn't better or worse than the other."
    Brainf*ck, Whitespace, and Unlambda, for example, were specifically
    designed to be bad languages, and they are. Perl was not specifically
    designed to be a bad language, but it is (IMHO of course) for many of
    the same reasons that the aforementioned languages are bad.

    You write:

    > I think any
    > journeyman programmer can follow the logic even if he doesn't
    > understand Perl or the data structures


    Maybe I don't qualify as a journeyman I can't follow that Perl code, and
    for exactly the same reason that I can't follow Brainf*ck code: too much
    punctuation. What does !~ mean? What do the curly braces denote? What
    is /\d/? And if I don't know the answers, how do I look them up? (Yes,
    I tried Perldoc. It didn't help.)

    The Lisp code, by contrast, has only three items of punctuation that I
    have to understand: parentheses, double quotes, and the colon. All the
    rest is English words. Some of those words might be mysterious (like
    CONS) but at least I can plug those into a search engine to obtain
    additional clues. And the double quotes mean exactly what they mean in
    common usage, so that leaves only two punctuation marks to deal with.

    Also, others have mentioned this but it's worth reiterating: you've
    taken actual working Perl code and compared it to a Lisp example
    specifically designed to be pathological. That doesn't exactly make it
    a fair fight. You can write obfuscated code in any language.

    > Perl uses sigils ($, !, %, &) to signify a token's usage.


    No, Perl uses sigils to indicate a variable's data type, not a token's
    usage. Except that it doesn't. It distinguishes between scalars,
    lists, and hash tables, but not between integers, floats, and strings.
    It distinguishes between strings and regular expressions, but not
    between strings and code. It has all kinds of weird punctuationy things
    that you can't look up, like $@ and !~ and <>. It fails silently where
    it should produce errors. It violates universally accepted conventions
    about what, for example, double quotes mean. For example, this:

    print "The widget costs $12.75.";

    The actual behavior of that code snippet is not justifiable under any
    sane language semantics.

    I could go on and on. But life is short. If you really want to
    continue this discussion (and if you do you really ought to consider
    getting yourself a life instead) I'd suggest starting with a pair of
    examples that do more or less the same thing so we can compare apples
    and apples.

    rg
    Ron Garret, Mar 10, 2010
    #6
  7. ccc31807

    ccc31807 Guest

    On Mar 10, 11:03 am, Tamas K Papp <> wrote:
    > > Not my intent to start a flame war. Please reread my post.

    >
    > Yeah, sure.  Cross-posting something like this usually promotes peace
    > and happiness.


    You still haven't read my post, or if you did you haven't comprehended
    it. There's nothing in it that works against peace and happiness. I
    actually wanted to increase peace and happiness insofar as in my power
    to do so.

    > >> Here's the point: to call one language horrible and an abomination
    > >> because you don't understand it, and ignoring the horribleness and the
    > >> abominable in another language because you do understand it, doesn't
    > >> make any sense.

    >
    > You failed to show anything horrible or abominable in CL.


    That's right. There isn't anything horrible or abominable in either of
    the two languages. It certainly wasn't my intention to create that
    impression, just to opposite in fact.

    Somehow, you think that I've said exactly the opposite of what I
    meant. Either I wasn't clear in my writing, or you weren't clear in
    your reading. I'll try one more time.

    <emphasis>Calling a language horrible because you don't understand it
    is a mindless prejudice.</emphasis>
    A
    Do you understand that? I contrasted a bit of working Perl code (which
    appears to be abominable) to a deliberately obfuscated bit of Lisp
    code to make that point. I really don't understand why you think I
    have insulted CL, when I undertook to say that insult based on
    ignorance is pointless.

    CC.
    ccc31807, Mar 10, 2010
    #7
  8. ccc31807

    Guest

    On Wed, 10 Mar 2010 09:45:20 -0800, Ron Garret <> wrote:

    >It has all kinds of weird punctuationy things
    >that you can't look up, like $@ and !~ and <>. It fails silently where
    >it should produce errors. It violates universally accepted conventions
    >about what, for example, double quotes mean. For example, this:
    >
    >print "The widget costs $12.75.";
    >
    >The actual behavior of that code snippet is not justifiable under any
    >sane language semantics.
    >


    q{$12} =~ /((((((((((((...))))))))))))/;
    print "The widget costs $12.75.";
    --
    The widget costs $12.75.

    Works for me.

    -sln
    , Mar 10, 2010
    #8
  9. Ron Garret <> wrote:
    >Maybe I don't qualify as a journeyman I can't follow that Perl code, and
    >for exactly the same reason that I can't follow Brainf*ck code: too much
    >punctuation. What does !~ mean?


    perldoc perlop:
    Binary "!=" returns true if the left argument is numerically not equal
    to the right argument.

    > What do the curly braces denote?


    Depends on where they are used. Some common uses include enclosure of
    code block (perldoc perlsyn) and indexing of hashes (perldoc perldata).

    > What is /\d/?


    perldoc perlre:
    In addition, Perl defines the following:
    \d Match a digit character

    >And if I don't know the answers, how do I look them up? (Yes,
    >I tried Perldoc. It didn't help.)


    It's all there. Granted, in particular perlop is hopelessly overloaded
    and therefore information is hard to find, but you are very welcome to
    improve it.

    >The Lisp code, by contrast, has only three items of punctuation that I
    >have to understand: parentheses, double quotes, and the colon. All the
    >rest is English words. Some of those words might be mysterious (like
    >CONS) but at least I can plug those into a search engine to obtain
    >additional clues. And the double quotes mean exactly what they mean in
    >common usage, so that leaves only two punctuation marks to deal with.


    In other words: you have a very limited vocabulary. Sure, that makes it
    much easier to learn the vocabulary, there are just much fewer words to
    learn. But at the same time you are paying for this advantage with
    lenghty sentences (=code) to express the same content (=algorithm).
    Wasn't it the Inuit language, that has over 50 different words for snow?
    To express the same differentiation in other languages you need half a
    sentence for what Inuit can do in a single word.

    >Also, others have mentioned this but it's worth reiterating: you've
    >taken actual working Perl code and compared it to a Lisp example
    >specifically designed to be pathological. That doesn't exactly make it
    >a fair fight. You can write obfuscated code in any language.


    That Perl code clearly qualifies as obfuscuted, no sane programmer would
    write code like that. Ben already demonstrated how equivalent, actual,
    readable Perl code would look like.

    >> Perl uses sigils ($, !, %, &) to signify a token's usage.

    >
    >No, Perl uses sigils to indicate a variable's data type, not a token's
    >usage.


    Correct.

    >Except that it doesn't. It distinguishes between scalars,
    >lists, and hash tables, but not between integers, floats, and strings.


    Why would you want to distinguish between them on such a low level? A
    scalar is all those simultaneously and you can use whichever version you
    need at any given moment. No awkward conversion from int to string only
    because you want to print that value, no need for special conversion
    from text (just read from a file or user input) to floating point to do
    some calculations. Seems very convenient to me.

    >It distinguishes between strings and regular expressions,


    Well, those are very different animals. Strings are data while REs are
    code.

    >but not between strings and code.


    Perl most certainly does clearly differentiate between strings (=data)
    and code, although you can breach the border using eval() or in REs.

    >It has all kinds of weird punctuationy things
    >that you can't look up, like $@ and !~ and <>.


    Yes, you can. See perldoc perlvar, perldoc perlop, perldoc perlop.

    >It fails silently where
    >it should produce errors. It violates universally accepted conventions
    >about what, for example, double quotes mean. For example, this:
    >
    >print "The widget costs $12.75.";
    >The actual behavior of that code snippet is not justifiable under any
    >sane language semantics.


    If you don't want variables ($12) to be interpolated, then don't use
    quotes that interpolate variables:

    print 'The widget costs $12.75.'

    jue
    Jürgen Exner, Mar 10, 2010
    #9
  10. ccc31807 <> wrote:
    >I contrasted a bit of working Perl code (which
    >appears to be abominable)


    That code is abominable and obfuscated, but of course you can write
    abominable and obfuscated code in any programming language.

    jue
    Jürgen Exner, Mar 10, 2010
    #10
  11. ccc31807

    John Bokma Guest

    John Bokma, Mar 10, 2010
    #11
  12. ccc31807

    ccc31807 Guest

    On Mar 10, 1:48 pm, Jürgen Exner <> wrote:
    > That code is abominable and obfuscated, but of course you can write
    > abominable and obfuscated code in any programming language.


    That code is hard read, but it's not obfuscated. The variable 'names'
    represent scalar values, in this case, an 'integer' used as a key. The
    convoluation comes from Perl's awkward syntax for multi-level data
    structures, in this particular case, a hash element that consists of
    an anonymous hash, thus
    $sec{$k}{'xlist'}
    in a foreach loop (which I omitted) like this
    foreach my $key (keys %sec) { ...$sec{$key}{'xlist'}... }
    and
    $fac{$sec{$key}{'id1'}}{'location'}
    simply references the $sec{$key}{'id1'} element in
    $fac{KEY}{'location'}

    This isn't harder than C pointers.

    And yes, I could have aliased the hash references to more readable
    variable names, but I wrote the code, I'm reading the code, and I'm
    maintaining the code ... why should I have to think of a redundant
    variable name when I have the hash assignments a few lines above this?

    my %fac;
    while (<SOME_DATA_SOURCE>)
    {
    chomp;
    my ($id, $site, $location, ... ) = split;
    $fac{$id} = {
    id => $id,
    site => $site,
    location => $location,
    ...
    };
    }

    The script is a short one, about 40 lines of code excluding comments,
    use statements, etc., and wouldn't give a Perl programmer any problem.

    CC
    ccc31807, Mar 10, 2010
    #12
  13. ccc31807 <> wrote:
    >On Mar 10, 1:48 pm, Jürgen Exner <> wrote:
    >> That code is abominable and obfuscated, but of course you can write
    >> abominable and obfuscated code in any programming language.

    [...]
    >$fac{$sec{$key}{'id1'}}{'location'}


    Thank you for confirming my point.

    >This isn't harder than C pointers.


    Saying something isn't harder than C pointers is like saying a desease
    isn't worse than the Bubonic plague: it gives very little comfort to
    people suffering from it.
    Actually C pointers are probably among the worst concepts ever invented
    in computer science.

    jue
    Jürgen Exner, Mar 10, 2010
    #13
  14. ccc31807

    John Bokma Guest

    Jürgen Exner <> writes:

    > ccc31807 <> wrote:
    >>On Mar 10, 1:48 pm, Jürgen Exner <> wrote:
    >>> That code is abominable and obfuscated, but of course you can write
    >>> abominable and obfuscated code in any programming language.

    > [...]
    >>$fac{$sec{$key}{'id1'}}{'location'}

    >
    > Thank you for confirming my point.
    >
    >>This isn't harder than C pointers.

    >
    > Saying something isn't harder than C pointers is like saying a desease
    > isn't worse than the Bubonic plague: it gives very little comfort to
    > people suffering from it.
    > Actually C pointers are probably among the worst concepts ever invented
    > in computer science.


    They are not "invented" they are somewhat a 1:1 mapping to
    assembly. I've never had problems with C pointers but that's most likely
    also because I had programmed in Z80 assembly [1] (and some motorola
    processors) for a few years before programming in C.

    I do agree, however, that it would've been nice if C had references like
    Perl, and (harder to get to) pointers as they are now. That, and a
    better standard library.

    Disclaimer: haven't programmed in C for a while.

    [1] including hacking a subset of Forth :-D.

    --
    John Bokma j3b

    Hacking & Hiking in Mexico - http://johnbokma.com/
    http://castleamber.com/ - Perl & Python Development
    John Bokma, Mar 10, 2010
    #14
  15. ccc31807

    Ron Garret Guest

    In article <>,
    J?rgen Exner <> wrote:

    > Ron Garret <> wrote:
    > >Maybe I don't qualify as a journeyman I can't follow that Perl code, and
    > >for exactly the same reason that I can't follow Brainf*ck code: too much
    > >punctuation. What does !~ mean?

    >
    > perldoc perlop:
    > Binary "!=" returns true if the left argument is numerically not equal
    > to the right argument.


    What does that have to do with what I asked?

    > > What do the curly braces denote?

    >
    > Depends on where they are used. Some common uses include enclosure of
    > code block (perldoc perlsyn) and indexing of hashes (perldoc perldata).


    Yes, that is exactly the problem. Perl is not content with assigning
    semantics meaning to every single symbol on the keyboard, it *overloads*
    those symbols, so even if you *could* look them up you *still* wouldn't
    know what they meant without first deciphering the context.

    > > What is /\d/?

    >
    > perldoc perlre:


    And how is one supposed to know that "perlre" is the right thing to look
    up here?

    BTW, these are all rhetorical questions.


    > It's all there. Granted, in particular perlop is hopelessly overloaded
    > and therefore information is hard to find, but you are very welcome to
    > improve it.


    And why on earth would I want to do that? No, seriously, what's the
    payoff? That is not a rhetorical question. What will I be able to do
    if I invest effort into learning and/or improving Perl that I cannot do
    just as easily and just as well in, say, Python?

    > >The Lisp code, by contrast, has only three items of punctuation that I
    > >have to understand: parentheses, double quotes, and the colon. All the
    > >rest is English words. Some of those words might be mysterious (like
    > >CONS) but at least I can plug those into a search engine to obtain
    > >additional clues. And the double quotes mean exactly what they mean in
    > >common usage, so that leaves only two punctuation marks to deal with.

    >
    > In other words: you have a very limited vocabulary.


    No. A limited grammar and a limited vocabulary are not the same thing.
    I can generate new symbols whenever I need them. I can even composulate
    fragulards of existentialized symboloids to imposulate novelish
    intentionalitizing and you even stand a fighting chance of figuring out
    what I mean.

    > Sure, that makes it
    > much easier to learn the vocabulary, there are just much fewer words to
    > learn. But at the same time you are paying for this advantage with
    > lenghty sentences (=code) to express the same content (=algorithm).


    http://rondam.blogspot.com/2008/02/z-shrtr-bttr.html

    > Wasn't it the Inuit language, that has over 50 different words for snow?


    No, that's a myth.

    > >Except that it doesn't. It distinguishes between scalars,
    > >lists, and hash tables, but not between integers, floats, and strings.

    >
    > Why would you want to distinguish between them on such a low level?


    Why would I want to distinguish between types at all?

    > >It distinguishes between strings and regular expressions,

    >
    > Well, those are very different animals. Strings are data while REs are
    > code.


    Potato, potahto. Strings are code when you feed them to EVAL.

    > >It has all kinds of weird punctuationy things
    > >that you can't look up, like $@ and !~ and <>.

    >
    > Yes, you can. See perldoc perlvar, perldoc perlop, perldoc perlop.


    Let me be more precise: that you can't look up unless you know the
    secret incantation.

    > >It fails silently where
    > >it should produce errors. It violates universally accepted conventions
    > >about what, for example, double quotes mean. For example, this:
    > >
    > >print "The widget costs $12.75.";
    > >The actual behavior of that code snippet is not justifiable under any
    > >sane language semantics.

    >
    > If you don't want variables ($12) to be interpolated, then don't use
    > quotes that interpolate variables:
    >
    > print 'The widget costs $12.75.'


    Yes, I know that. But what kind of brain damaged language allows
    numbers to be the names of variables in the first place? (That's
    another rhetorical question BTW.)

    rg
    Ron Garret, Mar 10, 2010
    #15
  16. John Bokma <> wrote:
    >Jürgen Exner <> writes:
    >
    >> ccc31807 <> wrote:
    >>>On Mar 10, 1:48 pm, Jürgen Exner <> wrote:
    >>>> That code is abominable and obfuscated, but of course you can write
    >>>> abominable and obfuscated code in any programming language.

    >> [...]
    >>>$fac{$sec{$key}{'id1'}}{'location'}

    >>
    >> Thank you for confirming my point.
    >>
    >>>This isn't harder than C pointers.

    >>
    >> Saying something isn't harder than C pointers is like saying a desease
    >> isn't worse than the Bubonic plague: it gives very little comfort to
    >> people suffering from it.
    >> Actually C pointers are probably among the worst concepts ever invented
    >> in computer science.

    >
    >They are not "invented" they are somewhat a 1:1 mapping to
    >assembly.


    Exactly. You can hardly do worse than that ;-)

    But in all fairness, when C was developed in the early 70s it was a
    major step forward and Kerningham and Ritchie could not possibly have
    known as much as we do today. For its time it was a great concept and
    implementation. It's just that it is way outdated 40 years later.

    > I've never had problems with C pointers but that's most likely
    >also because I had programmed in Z80 assembly [1] (and some motorola
    >processors) for a few years before programming in C.


    Well, not much Z80 but quite a bit 6502 here in this corner.

    >I do agree, however, that it would've been nice if C had references like
    >Perl, and (harder to get to) pointers as they are now.


    Or even Pascal or Modula or Haskell or pick pretty much any more modern
    language. However you cannot blame a 40 year old language for reflecting
    the thinking of 40 years ago.

    jue
    Jürgen Exner, Mar 10, 2010
    #16
  17. Ron Garret <> wrote:
    >In article <>,
    > J?rgen Exner <> wrote:
    >
    >> Ron Garret <> wrote:
    >> >Maybe I don't qualify as a journeyman I can't follow that Perl code, and
    >> >for exactly the same reason that I can't follow Brainf*ck code: too much
    >> >punctuation. What does !~ mean?

    >>
    >> perldoc perlop:
    >> Binary "!=" returns true if the left argument is numerically not equal
    >> to the right argument.

    >
    >What does that have to do with what I asked?


    Sorry, my bad:
    Binary "!~" is just like "=~" except the return value is negated in
    the logical sense.

    >> > What do the curly braces denote?

    >>
    >> Depends on where they are used. Some common uses include enclosure of
    >> code block (perldoc perlsyn) and indexing of hashes (perldoc perldata).

    >
    >Yes, that is exactly the problem. Perl is not content with assigning
    >semantics meaning to every single symbol on the keyboard, it *overloads*
    >those symbols, so even if you *could* look them up you *still* wouldn't
    >know what they meant without first deciphering the context.


    You mean like lead and lead in English? Or + and + in C which, gasp, can
    be used for char, short, byte, int, long, float, pointers, and a myriad
    of others?

    >> > What is /\d/?

    >>
    >> perldoc perlre:

    >
    >And how is one supposed to know that "perlre" is the right thing to look
    >up here?


    Because you were looking at a function who's first argument is a regular
    expression and therefore checking out the documentation about regular
    expressions as mentioned at the root level of the documentation in
    "perldoc perl" seems like a good idea?

    >BTW, these are all rhetorical questions.
    >
    >
    >> It's all there. Granted, in particular perlop is hopelessly overloaded
    >> and therefore information is hard to find, but you are very welcome to
    >> improve it.

    >
    >And why on earth would I want to do that? No, seriously, what's the
    >payoff? That is not a rhetorical question. What will I be able to do
    >if I invest effort into learning and/or improving Perl that I cannot do
    >just as easily and just as well in, say, Python?


    True, for you it would be a major drawback because you couldn't rant
    about it any longer.

    [...]
    >> >Except that it doesn't. It distinguishes between scalars,
    >> >lists, and hash tables, but not between integers, floats, and strings.

    >>
    >> Why would you want to distinguish between them on such a low level?

    >
    >Why would I want to distinguish between types at all?


    So are you suggesting that e.g. C's distinction between short, byte,
    char, int, long, unsigned, double, ultra-special-extra-big .... would be
    even better?
    Typing is an aid to the programmer to avoid errors by inadvertently
    using incompatible data types. However if the programming language
    automatically converts between different data types according to context
    and I can use them safely without ever thinking about a conversion, then
    that is as big a step forward as not having to manually deal with memory
    allocation and garbage collection of dynamic data structures.

    >> >It distinguishes between strings and regular expressions,

    >>
    >> Well, those are very different animals. Strings are data while REs are
    >> code.

    >
    >Potato, potahto. Strings are code when you feed them to EVAL.


    I think I did mention eval(). And yes I also mentioned that eval() (as
    well as RE when used with /e which is just an eval in disguise) breaks
    the paradigm. But still this is only one very specific place which you
    normally would not use in every-day code. Actually people are strongly
    advised not to use eval for strings unless they know exactly why they
    need to do it.

    >> >It has all kinds of weird punctuationy things
    >> >that you can't look up, like $@ and !~ and <>.

    >>
    >> Yes, you can. See perldoc perlvar, perldoc perlop, perldoc perlop.

    >
    >Let me be more precise: that you can't look up unless you know the
    >secret incantation.


    Where's the problem? Any item with a $ up front is a variable, so you
    will probably find it in perldoc perlvar. The other two take arguments
    and do some computation. So chances are good you will find them either
    as functions (perldoc -f .....; no luck there) or in perldoc perlop as
    suggested by the root of the perldoc tree.

    >> >It fails silently where
    >> >it should produce errors. It violates universally accepted conventions
    >> >about what, for example, double quotes mean. For example, this:
    >> >
    >> >print "The widget costs $12.75.";
    >> >The actual behavior of that code snippet is not justifiable under any
    >> >sane language semantics.

    >>
    >> If you don't want variables ($12) to be interpolated, then don't use
    >> quotes that interpolate variables:
    >>
    >> print 'The widget costs $12.75.'

    >
    >Yes, I know that. But what kind of brain damaged language allows
    >numbers to be the names of variables in the first place? (That's
    >another rhetorical question BTW.)


    A language that wants something better than \12 as a variable name for
    captured content from the 12th RE group?

    jue
    Jürgen Exner, Mar 10, 2010
    #17
  18. ccc31807

    ccc31807 Guest

    On Mar 10, 12:45 pm, Ron Garret <> wrote:
    > Most of what I have to say about this has already been said by other
    > people, but since this post is addressed specifically to me I'll respond
    > nonetheless.


    Thank you. This is the thoughtful, mature response that I hoped for,
    rather than the rant that I feared.

    > > I think any
    > > journeyman programmer can follow the logic even if he doesn't
    > > understand Perl or the data structures

    >
    > Maybe I don't qualify as a journeyman I can't follow that Perl code, and


    You don't give yourself enough credit:
    if (CONDITION 1) assign A to VAR
    else if (CONDITION 2) assign B to VAR
    else assign C to VAR

    > What
    > is /\d/?


    from perlre:
    \d Match a digit character

    > that you can't look up, like $@ and !~ and <>.


    from perlvar:
    $@ The Perl syntax error message from the last eval() operator.

    from perlop:
    The null filehandle <> is special: it can be used to emulate the
    behavior of sed and awk. Input from <> comes either from standard
    input, or from each file listed on the command line.

    Binary ``!~'' is just like ``=~'' except the return value is negated
    in the logical sense.

    > print "The widget costs $12.75.";


    Variable interpolation allows you to avoid stuff like this:
    print "The widget costs $" + var ".";
    If you don't want variable interpolation, use single quotes:
    'The widget costs $12.75.'
    If you want to use double quotes, escape $:
    "The widget costs \$12.75."

    > The actual behavior of that code snippet is not justifiable under any sane language semantics.


    Please see my justification above.

    >  If you really want to
    > continue this discussion


    I really don't want to continue this discussion. I've said all I
    intended to say, which was to respond to your remark that I quoted in
    the original post. I respect your right to have an opinion, but I
    don't respect your screed because it seemed to me to be based on
    prejudice and ignorance.

    My job entails querying databases and munging the data, and Perl is
    well suited for this task -- after a bit of experience you can write
    an assignment statement like:
    $fac{$sec{$k}{'id1'}}{'location'} =
    $sec{$sec{$k}{'xlist'}}{'site'};
    without pausing to work out the fact that you are assigning the value
    of a key to an anonymous hash held as a reference by the second hash
    key to a key of an anonymous hash held as a reference by a key to the
    first hash. Perl is a fat, ugly, old bitch but she makes some jobs
    easy. You can justifiably criticize her appearance, and you can say
    that you were unable to live with her, but you can't say that she IS
    'horrible' and 'abominable' based on her appearance or the fact that
    you can't live with her. She actually has a very sweet disposition
    once you get to know her.

    Ron, this isn't meant to insult you, or the Lisp community, or the
    Perl community for that matter. Thanks for your response.

    CC.
    ccc31807, Mar 10, 2010
    #18
  19. ccc31807

    Ron Garret Guest

    In article
    <>,
    ccc31807 <> wrote:

    > On Mar 10, 12:45 pm, Ron Garret <> wrote:
    > > Most of what I have to say about this has already been said by other
    > > people, but since this post is addressed specifically to me I'll respond
    > > nonetheless.

    >
    > Thank you. This is the thoughtful, mature response that I hoped for,
    > rather than the rant that I feared.


    I'm not Erik even though I may occasionally agree with some of his
    positions.

    > Perl is a fat, ugly, old bitch but she makes some jobs
    > easy. You can justifiably criticize her appearance, and you can say
    > that you were unable to live with her, but you can't say that she IS
    > 'horrible' and 'abominable' based on her appearance or the fact that
    > you can't live with her. She actually has a very sweet disposition
    > once you get to know her.


    I don't know why you think "fat, ugly, old bitch" is more acceptable as
    hyperbole than "horrible" and "abominable" but to me they are equivalent
    sentiments. Perl's syntax is IMHO very badly designed. Python
    dominates Perl in every conceivable way IMHO. I've had one firsthand
    experience with Perl in production that turned out very badly. If
    you're productive in Perl, more power to you. But you won't be working
    for me.

    > Ron, this isn't meant to insult you, or the Lisp community, or the
    > Perl community for that matter. Thanks for your response.


    You bet.

    rg
    Ron Garret, Mar 10, 2010
    #19
  20. ccc31807

    ccc31807 Guest

    On Mar 10, 5:56 pm, Ron Garret <> wrote:
    >  Python
    > dominates Perl in every conceivable way IMHO.


    I did a project in Python, once, and it turned out well. Python is a
    sweet language, and I understand that they are now teaching it as the
    first language at both MIT and GaTech.

    > I've had one firsthand
    > experience with Perl in production that turned out very badly.


    Was that because Perl was a bad match for the project? Or because the
    developers were incompetent in Perl? I've done several major database
    projects in Perl, and a great number of minor projects in Perl, and my
    experience is that the match of a technology to a task sometimes is a
    management decision, and managers sometimes make bad decisions.

    > If
    > you're productive in Perl, more power to you.  But you won't be working
    > for me.


    I won't be working for you anyway. I've reached my level of
    incompetence, and I intend to stay there! ;-)

    CC
    ccc31807, Mar 10, 2010
    #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. Xah Lee
    Replies:
    11
    Views:
    586
    Bart Willems
    May 8, 2007
  2. ekzept
    Replies:
    0
    Views:
    363
    ekzept
    Aug 10, 2007
  3. nanothermite911fbibustards
    Replies:
    0
    Views:
    370
    nanothermite911fbibustards
    Jun 16, 2010
  4. nanothermite911fbibustards
    Replies:
    0
    Views:
    315
    nanothermite911fbibustards
    Jun 16, 2010
  5. T.Oakley
    Replies:
    9
    Views:
    105
    Kristof Bastiaensen
    Apr 9, 2004
Loading...

Share This Page