do...until wisdom needed...

[Steve Lamb]

On 17 Apr 2001 19:02:54 -0400, Douglas Alan <nessus at mit.edu> wrote:
>Good for *you*.  *I* find everything to do with Perl a chore.  Reading
>the manual is a chore, writing programs in it is a chore, maintaining
>programs in it is a chore, talking to fans of it is a chore.  It is
>utterly unpleasant from the ground up.

    I dunno, I find most of what I write in it quite easy compared to Python
at the moment.  Of course, this are the simple cases where while(<>){}, or
while(<FOO>){} is far easier than the comparable Python loops.  OTOH, I would
not trade in the Python loops since it, too, has its advantages.  Mainly if
not meaning if not and only if not meaning if not.

>How do you know?  Have you ever programmed in a language with
>procedural macros?  I have.  And I know from direct, first-hand
>experience, that maintaining programs that judiciously use procedural
>macros *increases* the maintainability of the code, not decreases it.

    Just as maintaining programs that are judiciously programmed in Perl
increases the maintainability of the code.  Just as maintaining programs that
are judiciously programmed in Python increases the maintainability of the
code.  The operative word is judicious, not procedural macros.

>Yes, a good argument against Perl.  Not a good argument against
>procedural macros.

    Incorrect, it is a good argument against both.

>No it doesn't.  Perl is an attrocity.  Please don't compare my desire
>for procedural macros to a desire anything like Perl.  Lisp has
>procedural macros -- it is *nothing* like Perl.

    I call it like it is.  You want a way to do the same thing multiple ways
that causes a maintenance nightmare for anyone else who has to even look at
your code.  Perl has that, hence you are aspiring to Perl, which you dispise.
Kinda like that whole homophobes are closet gays.  You're a closet Perl
zealot.

>You speak using armchair logic and not from real-world experience.

    I speak using real-world experience.  

>This has never been a problem with Lisp code that I have worked on.
>Good programmers are sane enough to not make their code particularly
>idiomatic and bad programmers can always find a way to make their code
>unbearable, even in Python.

    Yes, and?  This has no bearing on the fact that providing multiple ways to
do things makes a language complex out of perportion of the benefits provided.

>> It means every time you come in contact with a new person's programs
>> you have to relearn thier particular dialect of the language.  That
>> is not something that can be learned in a day.

>In *theory* perhaps.  In the real world, no.

    Hint, you're the one with the theory.  Here's the real world; touch
someone else's code where they can modify semantics and you have to learn
their dialect.

>> > That's because Perl is the worst attrocity foisted on humanity since
>> > the black plague.

>>     Yet it offers exactly what you want.  So why, then, do you want to turn
>> Python into the worst attrocity foisted on humanity since the black plague?

>You speak in non-sequitors.  I don't want Python to be *anything* like
>Perl.  

    Yes, you do.  You want to be able to provide multiple ways to do the same
thing.

>A language without procedural macros is clearly less expressive than
>one that has them.  

    A language without procedural macros is clearly easier to maintain.  To
me, that is power.

>This statement needs no support.

    Wow.  Really?  This statement needs no support either: *plonk*.

>For instance, if I had procedural macros, I wouldn't need to bug the language
>implementers to add variable declarations -- I could do it myself.  This
>would significantly reduce the amount of time I spend debugging mistakes that
>should have been caught by the language.  This should make everyone happy.

    Except for those who have to touch your code and then wonder why the
language doesn't work like they learned it.  They then need to learn your
particular dialect of the language.  Try to 'no support' your way out of that.

>> All I see are programmers who are whining that they can't have their
>> favorite construct instead of learning a new way to do things.

>I understand perfectly well the Python way of doing things.  In my
>case, the supposed Python way isn't always up to snuff.  It has
>nothing to do with not willing to learn something new -- it has to do
>with me having years of experience knowing what I need to be as
>productive as possible.

>> All I see are programmers who are whining that they can't have their
>> favorite construct instead of learning a new way to do things.

    Am I prophetic, or what?  

>> Ironic in that to implement their pet prodecure they are requiring
>> everyone /ELSE/ to learn something new.

>Why is everyone here such a cynic?  I hear claims that the Python
>community is supposed to be filled with such nice people.  You could
>have fooled me.  It seems to be filled with people that like to talk
>down to others, patronize them, and trivialize their concerns.

    Prime example, |>ouglas "1 sp3 at k d00d" Alan.  Take a look at your comments
on Perl sometime.

>> But is something that every expert would have to relearn each time they
>> tuch someone else's code.

>Everytime you read someone else's code you have to understand the
>functions they've defined before you can understand their code.  Let's
>get rid of functions too!

    That is a part of the language.  Redefining the very semantics and syntax
of the language means it is a new dialect.  If the big words are hard for you
to understand visit <http://www.m-w.com>.

-- 
         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
         ICQ: 5107343          | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------