do...until wisdom needed...

[Douglas Alan]

grey at despair.rpglink.com (Steve Lamb) writes:

> > Personally, I want a language that gives me all the rope I need,
> > but doesn't make it a chore to write good programs.  Writing good
> > programs in Perl is a chore; hence Perl sucks.

> Perl gives you all the rope that you need.  Writing good programs in
> Perl is not a chore.  Maintaining good programs in Perl is a chore.

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.

>     Writing good programs in Python now isn't a chore.  The more I
> program in Perl, the more I want to program in Python because of the
> fact that there are less ways to do something.  By giving macros
> you'd be giving more ways to do something and lower the
> maintainability of the code.

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.

>     The problem isn't that the language isn't flexible enough; it is
> plenty flexible for the aims it has.  The problem is that the
> programmers aren't flexible enough in their laziness.  It is
> something that I've had to overcome time and again in my Python
> programming because of my Perl background.  As I've said, however, I
> prefer Python because I know that I'm quite likely to be able to
> maintain someone else's three year old code without having to puzzle
> over it for an hour and spend another three rewriting it to a
> maintainable form.

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

> > Regarding Perl, it is the worst attrocity foisted on humanity
> > since the black plague.

>     Yet it provides exactly what you want, TIMTOWTDI.  

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.

> Yes, it does.  It means that a person, beginner or expert, has to
> relearn a particular person's idioms before being able to do
> anything productive.

You speak using armchair logic and not from 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.

> 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.

> > 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.  If anything, I want it to borrow some good ideas from Lisp.
Lisp is nothing like Perl.  Lisp, like Python, is a wonderful
language, it it would behove both languages to learn lessons gleaned
by the other.

> > A language should be easy to learn, but offer untold power.  

> Thus far I don't see many limits to Python's power because of its
> simplicity.

A language without procedural macros is clearly less expressive than
one that has them.  This statement needs no support.  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.

> 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.

> 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.

> > If Python had procedural macros, the language wouldn't be any
> > harder to learn since this is not something a newbie would have to
> > worry about for quite some time.

> 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!

> > A bad programmer has many tools available to him in Python, as it
> > is, to make hard to understand code.  I don't think it would go
> > over well to remove useful features from the language to prevent
> > this.

> This, of course, is also not an argument to add features which serve very
> little purpose and add untold complexity.

If you think that procedural macros "serve very little purpose and add
untold complexity", then you are profoundly ignorant on the history of
just how useful they have been in the programming languages that have them.

> You said you programmed quite happily in Lisp for over a year
> without macros.  I contend that if the macros weren't there you
> could have still programmed just as happily.

Actually, you are quite wrong.  I got to a point where I needed
certain features (like object-orientation and exceptions) that weren't
in the language, and I needed to implement them in order to accomplish
my task.

|>oug