do...until wisdom needed...

[Douglas Alan]

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

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

I can't make "judicious use of procedural macros" if I don't *have*
procedural macros.  Thus, without procedural macros, some avenues
opened up to me for making my code more readable are lost.

You seem to be claiming that "judicious use of procedural macros"
could not *possibly* make my code more readable.  If that is what you
are claiming, I have much real world experience that says you are wrong.

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

>     Incorrect, it is a good argument against both.

You are wrong for two reasons: (1) My problems with Perl run far, far
deeper than that it gives you too many ways to do the same thing.  (2)
Yes, procedural macros *can* be used by the novice to just give you
yet another way to do something that you can do easily enough using a
built-in, but that is not where their strengths lie.  Their strength
lie in allowing the user to make a wholesale extension to the language
that greatly simplifies a complex task.  Can this be misused?  Most
definitely.  Have they proven themselves to also allow incredible
gains?  Absolutely.

For instance, procedural macros allowed Lisp to turn itself from a
procedural language to an OO language without changing the language at
all.  A very capable OO extention (one that supported multimethods and
a meta-object protocol) could be added to the language using only
macros.  The language was able to *grow* without any centralized
control.

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

I don't want to be able to so the same thing multiple ways.  I want to
be able to add extensions to the language, and to be able to reduce
redundant code by being able to parameterize such code using macros.

> 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 get nowhere with such reasoning, except to make me think that you
are ignorant about procedural macros and wish to remain that way.

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

>     I speak using real-world experience.  

You do?  Have you ever programmed in Lisp using procedural macros?

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

This is a straw man.  The "benefit" you mention is not the benefit I
care about.

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

I'm not speaking from theory -- I am speaking from direct experience.
I have used Lisp extensively and I *know* what benefits and pitfals
procedure macros entail.

By the way, procedural macros do not "modify semantics" -- they only
allow the programmer to define new syntactic forms.  They don't change
the meaning of the syntactic forms that are already there.

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

Straw man.

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

Untrue.  As I said before, I speak from direct experience that
procedural macros typically make programs easier to maintain, not more
difficult.

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

The language will still work exactly the way that they learned it.  It
will just be the case that there will be a new syntactic form.  The
new syntactic form will be no more difficult to understand than if I
defined a new function and used it.

> They then need to learn your particular dialect of the language.

By your definition, they need to learn a "new dialect" every time I
define a new function.

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

If you want to use Perl go ahead.  I just want *nothing* to do with
Perl, okay?  I don't talk down to people who ask me *Python*
questions, or *Lisp* questions, or *C++* questions, or *Java*
questions, if the questioner does so with even the slightest amount of
respect in their tone.

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

So?  It still allows programmers to define new terms that you have to
do some work to understand.  If procedural macros were added to the
language, then they'd be part of the language too, would they not?

> Redefining the very semantics and syntax of the language means it is
> a new dialect.

Procedural macros don't allow you to "redefine the very semantics and
syntax of the language".  They only allow you to add new terms to the
language, just as defining functions and objects allows you to add new
terms.  The type of term you can add to Python with a function is
somewhat limited compared to what you could add with procedural
macros.  Sometimes a more powerful term-adding capability is
incredibly useful and allows you to make programs that are more
elegant and easier to maintain.

> If the big words are hard for you to understand visit
> <http://www.m-w.com>.

%#@% you too.

|>oug