do...until wisdom needed...

[Steve Lamb]

    I's like an effing trainwreck.

On 17 Apr 2001 20:36:59 -0400, Douglas Alan <nessus at mit.edu> wrote:
>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.

    As are LOTS of avenues for making your code unreadable.

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

    No, I am claiming that the judicious use of anything programming related
seems to be inversely perportional to multitude of ways one can complete the
task.

    Put another way, programmers, like drivers, like to think they are above
average.  Experience, not to mention mathematics, show that programmers, just
like drivers, aren't all above average.  Food for though, |>0L|G?

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

    And?  This doesn't discount that macros are a large... well, several large
leaps in that direction.

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

    I'll have to keep that in mind.  "Make a wholesale extension to the
language."

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

    Hmmm-mmmm, what was that I was mentioning about dialects?

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

    IE, make your own dialect.

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

    And you're proving to me that you're the very zealot I mentioned who is
more interested in whining about not having his favorite constructs than
working with what is presented.  I still think you're a closet Perl Zealot,
too.

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

    I speak of having to maintain an extremely large codebase of TIMTOWTDI
code and shudder at the thought of having to deal with the "wholesale
extension to the language" to the extend of taking a procedural and turning it
into OO at the whimes of the dozens of programmers who have worked on this
code base.  I have enough trouble as it /is/ without the language itself being
(more of) a moving target!

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

    Whoop-di-do, it is a benefit mention in conjuction with what you are
advocating.  It /IS/ something that is going to happen so you had best be
ready to defend it.

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

    Clearly not.

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

    Deal with it.

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

    Pardon me if I don't take your word on it.

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

    Whoops, let's think about this.  "Wholesale extension to the language" and
turning a procedural language into something similar to OO.  Those do not jive
with "The language will still work exactly the way they have learned it."
Sorry, I do not believe you when you are touting a pseudo-OO from a non-OO
language as "exactly the same".  If it operated "exactly the same" then you
wouldn't have a NEED for the macros since, well, it isn't modifying anything
is it.  If it were, then it wouldn't be EXACTLY the same!  

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

    No, they do not.  Since the functions are written in the language and are
a part of the language they don't need to learn anything new to understand the
language.  They only need to reed the narrative that is there.  A new
dialect...  Wait, let's pause for a minute.  Clearly you are having trouble
with the big words and didn't take my advice.  From m-w.com...

a regional variety of language distinguished by features of vocabulary,
grammar, and pronunciation from other regional varieties and constituting
together with them a single language

    Distinguised by features of vocabulary, grammer and pronunciation.  I
chose that word because with macros you are changing how the language reacts
and acts.  Unlike with just defining a new function which is using existing
behaviors, IE, "vocabulary, grammer and pronunciation", to get the end result.

    That is why in one dialect of English "Put that fag out!" means to
extinguish a cigarette and in another it might mean to remove a gay individual
from a building or to knock them out with physical violence.  Just as in
natural languages where different DIALECTS alter the meaning and understanding
of the individual sentences macros would do the same for computer languages.
Functions do not because they use the existing langauge to create new things,
not alter the language to create new things.  READ THAT SENTENCE AGAIN, USE
THE WEB SITE FOR THE BIG WORDS.

    There is a difference there and if you're too dense to figure it out, your
own tough luck.  You're the one trying to sell the notion that macros which
can effect a "wholesale extenstion to the language" and even alter the
behavior of the base language (Lisp procedural to pseudo-OO) is even on the
same remote scale as a common function definition!  

>If you want to use Perl go ahead.  

    I'd much rather not to.  However, it pays the bills.

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

    But you talk down to people who ask Perl questions, clearly.  I don't talk
down to anyone asking honest questions.  Only to yahoos (that's a technical
term for |>00|> |>oUgsL3R, btw) who is saying one thing out of the left side
of his mouth (The language acts the same!!!) and something entirely different
out the other (The language has evolved, wholesale extensions, morphing from
one style of programming to another).  Sorry, Doug, one or the other, can't
have both so stop trying.

>So?  It still allows programmers to define new terms that you have to
>do some work to understand.  

    Written in the language we know, not redefining the language.  There is a
difference.

    Try this since you're so dense on the difference.  Ever wonder why
Legalese, while nominally English (well, in this country) is so hard for the
layman to read now?  1/2 the reason is because they like to redefine a word
for the scope of the document.  

    Taking existing words and putting them together in new ways = same
language = functions.

    Taking existing words, redefining them for only a short timeframe =
different DIALECT = macros.

>If procedural macros were added to the language, then they'd be part of the
>language too, would they not?

    No, see above.

>Procedural macros don't allow you to "redefine the very semantics and
>syntax of the language".  

    Not according to "Wholesale extenstion to the language"
OO-outta-procedural Douglas Alan.  Maybe you've heard of, oh wait, you're him.
Read the top of this message to see the appropriate quotes.  I'd call making
OO out of non-OO redefining the very semantics and syntax of the language.
Call me crazy, but C and C++, by most people, are considered two different
languages with the mane difference being...  Well, one is functional, the
other OO.  Wacky that, eh?

>They only allow you to add new terms to the language, just as defining
>functions and objects allows you to add new terms.  

    If that is all they did then why do we need them if we have that now with
fuctions.  Clearly that isn't all they do.  Call me crazy but maybe that
Douglas Alan guy, er, you, nailed it with "wholesale extensions to the
language".  Call me crazy but I don't consider programs written in the
language as wholesale extensions to the language.  I call them, well, programs
written *IN* the language as opposed to *ALTERING* the language.  And please,
no more BS about "it doesn't alter the language" ok?  "Wholesale extension of
the language" and making OO out of non-OO is altering the language, period.

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

    More elegant and easier to maintain... ...to the original author since he
is the one who wrote the dialect in the first place.  For everyone else, it is
a major pain in the rear since they now have to /LEARN/ the "wholesale
extension to the language".  You, uh, forgot that part, didn't you.  You are
aware other people are going to have to maintain your code.  And remember, in
spite of what you may think, there is a 50/50 chance you're a below average
programmer.

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

>%#@% you too.

    To me it is deserved.  You know why?  I'm a out-and-out prick.  I don't
suffer liars lightly and anyone, I do mean ANYONE who is trying to sell the
tripe your selling of altering a language without ever altering the language
is either trolling, smoking crack, or lying.  So %#@% (Hash, comment, array,
hasH?) me all you want.  But when it comes to Alex I best suggest a few
things, in order.

Sit down.
Shut up.
Read.
Learn.

    Alex has been uniformly polite and entirely too verbose in his/her (er,
sorry Alex) explinations of not only how certain things work but why they
work, why they were made to work that way and why alternatives have not been
implemented.  I have found Alex to be the single largest help on my transition
into Python and Pythonic thinking and have YET to find fault with his/her (er,
sorry Alex) reasoning.  So the next time you even think Alex is being rude,
read this reply to remind yourself of what rude (and correct) is.  Then follow
the above 4 steps.

Sit down.
Shut up.
Read.
Learn.

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